Autoit.ES

Hola

Bueno, esto seguro que es muymuymuy fuera de tema, incluso en este post, pero espero me perdoneis, y no respondais si no procede...

Resulta, que estoy empezando a tocar VB 6 ("El saber no ocupa lugar", "Lo que hace el aburrimiento")... Pero lo que es seguro, que alguna utilidad tendrá.

Estoy intentando hacer una dll, de esas que llaman "Normal", "Al estilo de las apis de Windows". Estaba siguiendo los pasos de esta página para hacerlo:
http://www.elguille.info/vb/avanzado/cr ... licado.htm

Todo ha ido bien, hasta el último paso, el de generar el archivo .dll, donde el VB 6 me da un error que dice (más o menos):
"Error:

No se ha podido cargar la bibioteca dll".

¿Sabeis que puede estar pasando, si todo lo anterior lo hice bien?.

En la página que he puesto, dicen que hay que cambiar el linker del VB por uno que hay que compilar para que se puedan hacer dll's "Normales",no se si eso ha de ser así, si tendrá algo que ver ... La cosa es, que compilé el código del linker que pone en esa página, y compiló sin problemas, luego no se si funcionará bien o no.

A ver si alguien sabe hecharme un cable, que por aquí hay gente que domina muy bien el VB.

Acias,

Salu2!

Juer Jonny, eres la pera.
Pero si te metes con otro lenguaje, como se te ocurre comenzar haciendo dlls??? . Antes tendrás que saber algo del lenguaje no?.
Pues está claro que si el código del link si te compila y el tuyo no es que algo has puesto mal .
Pero que sepas que ese código es algo facil. Que cuando mires como crear funciones, propiedades, métodos y eventos seguro que te vas a liar bien. Además, yo no te recomendaría el vb6 para programar, ya que fue avandonado hace tiempo por ms y no tiene ningún tipo de soporte.
Fijate, yo que he programado en vb6 durante años (creo que empezé con el vb5 en el año 97, pero me puse más serio cuando salió el vb6 en el 98) nunca me he animado a hacer una dll .

Yo es que hace unos 4 años que no toco el vb y lo tengo algo olvidado.

Por cierto, si vas a programar en vb6 asegurate de tenerlo actualizado con el último service pack (sp6).

Saludos.

jejejejejejeje...

Olvidé decir que antes de intentar hacer una dll, había por supuesto, mirado un manual de VB 6, y que no soy un experto, pero más o menos me manejo con ese lenguaje, almenos en las variables, bucles, funciones, condiciones... No me ha resultado muy difícil, porque la sintaxis es bastante parecida a la de AutoIt. Tanto que hay cosas que se hacen exactamente igual, como por ejemplo el For ... Next.

Resulta, que después de escribir el post, seguí insistiendo y acabó compilando. No se si porque recompilé el Link.exe pero especificándole en las preferencias del proyecto la ruta de Crrun.dll, o por algún error que tuviera antes en el .def (seguramente fuera eso), pero al final, conseguí compilar la maldita dll.

Eso sí, al probarla con AutoIt (hice una dll bien sencillita para no ponerme en un apuro a la hora de probarla) jeje, el script petaba al llamar la dll, y salía lo de los informes de errores de Windows.

Por lo que he leido y me ha dicho el autor del artículo de la página que puse, resulta que no funciona con cadenas, que es justo con lo que hice la prueba (la función recibía una cadena y la devolvía).

La verdad es que ya me lo han dicho igual que tú, que a estas alturas no es buena idea meterse con VB 6, pero meterse con cosas como .net, C# o el que me gustaría aprender enserio: C++, no es cualquier cosa.

Salu2!

¿VB6 o VB.NET?
Pues si ya sabes algo de VB, yo sí me pasaría al .NET, ahí tienes varios lenguajes que son equivalentes, y más potentes que VB6.
Ambos sistemas necesitan librerías y runtimes para ejecutarse, pero al menos .NET es una tecnología más moderna y aunque es más o menos interpretado digamos que es un intérprete de segunda generación. En principio compila a un lenguaje intermedio, MSIL, que significa precisamente Microsoft Intermediate Language. Cuando vas a ejecutarlo en ese momento se van pasando las instrucciones a código máquina con un compilador que se activa según se va necesitando, es lo que se llama un compilador JIT (Just In Time). Es parecido al Java, por eso necesita librerías para ejecutarse, en principio no crea EXEs autónomos que puedas ejecutar en un ordenador que no tenga el .NET (igual se puede forzar compilación completa para que no se necesite luego el JIT, si es así y alguien lo sabe me gustaría que nos lo comunique)
VB6 y anteriores compila también a un lenguaje intermedio, mucho más simple, en realidad tanto que técnicamente no es compilar, sino "toquenizar", que es codificar las instrucciones, variables y tal con números. Cuando va a ejecutarse las librerías del RunTime (vbrun60.dll y compañía) interpretan esos tokens y van generando código máquina para el procesador. Este es más o menos el mismo proceso que realiza AutoIt, estos son lenguajes interpretados.

.NET sin llegar a ser un compilado total es mucho más avanzado y te dará un rendimiento muchísimo mejor.

Sospecho que las DLL de .NET serán DLLs "más de verdad" que las que puedas hacer en VB6, y quizás no te sea tan difícil pasarte a VB.Net si ya sabes algo del otro.

Es muy interesante eso que haces, sólo por manejar otro lenguaje ya está bien, te abre los horizontes, pero además puedes ampliar funcionalidad para otros, por ejemplo hacer Dlls para usar desde AutoIt, como comentas.

También recuerda que hay foros de VB, lo normal no será poner las consultas aquí Por supuesto que no está mal hablar de estas cosas en el bloque de chat, pero cuando hagas consultas técnicas intenta enlazarlas con AutoIt de alguna manera, je, je.

Saludosssss

El conocimiento no ocupa lugar, pero según comenté, aquí sobre el robotic estudio http://www.emesn.com/autoitforum/viewto ... =fat#p8505 no me gusta que MS y otros hagan lenguajes FAT o sea gordos, que tengas que instalar un montón de librerias y runtime-engines, entornos, etc... para algo debe ser sencillo.
Es posible que un ejecutable en la próxima versión de .NET te ocupe 1 giga + 5 gigas los runtimes, vaya como un sistema operativo. No se hasta donde van a llegar. Aquí tienes otro lenguaje http://msdn.microsoft.com/en-us/robotics/aa731521.aspx .
Por cierto, hay millones de dlls que están hechas, funciones, librerias, APIS,
Como te dijeron, hay personas que llevan años programando y nunca han necesitado hacer un dll ya que lo han encontrado hecho.
¿Es que hay algo especial que quieras hacer que no esté AL nivel de dll, a bajo nivel que no puedas gestionar desde el lenguaje sin pasar a crear?
Salu22:)

Hola

Por supuesto, no es cosa de convertir esto en un foro de VB, aún siendo el sitio un poco de los of topics... Pero bueno, al haber visto que Chefito por ejemplo había dominado el VB, pues ...
Por supuesto, la idea es relacionar el tema de las dll con AutoIt, tampoco es mi idea olvidarme de él para empezar a trabajar con VB ni ningún otro lenguaje, porque sería complicarme demasiado la vida sin necesidad.

Está bien lo que dices de .net, sería lo lógico, solo por qué es más actual, es como querer aprender AutoIt 2, habiendo el 3.3.6.0, pero seguro que este último incluye muchas más funciones y requiere más trabajo el aprendérselas.
Pues con .net, es (para mí) mucho más exagerado, ya que se trata de lenguajes teóricamente más sofisticados que AutoIt, y por tanto la evolución debe ser más compleja. De .net, aprendería C#, tan de moda ahora, que dicen que es el presente y el futuro... Para gustos los colores, y además seguro que lo es, por su filosofía, pero yo he intentado meterme con ese lenguaje y no he aguantado más de 10 páginas (La POO) no está hecha para mí.

VB 6 me viene bien, por ser parecido al AutoIt, e implementar eso que AutoIt no tiene. Así pues, la idea era combinar ambos, para hacer programas de la complejidad que fuera con relativa facilidad, aunque como dice BasicOS, no es necesario hacer dll's para que un programa funcione, y hay miles, millones de ellas hechas por ahí, pero muchas veces son comerciales, otras has de aprender su funcionamiento (en ocasiones un poco difícil)... ¿Qué mejor que hacerlo uno mismo?

De esta forma, siempre tendrás una dll que haga exactamente lo que quieres y como quieres. Mi idea, es hacerlas, para usarlas con autoit en casos en los que hacer algo con este es muy rebuscado.

Por ejemplo, para el tema del OCR con la webcam, que posteé hace unos días, buscando "Manejar cam con vb" o cosas así en Google, hay cientos de páginas, con montañas de códigos, mientras que en el foro de AutoIt no hay tanta cosa. Siempre se puede hacer de todas formas en AutoIt, pero si adaptas un código ya hecho para el programa que estás haciendo, lo compilas como dll y luego solo tienes que usarlo en AutoIt ¿no se simplifica la faena?...

Ah, por cierto:

¡ya hice mi primera dll, que funciona y todo!

No se por qué, pero si le paso más parámetros de los que admite, o de otro tipo ... (si la provoco) es cuando casca el AutoIt.
¿Sabeis por qué, si es normal..., en vez de devolver el código de error en @Error?.
Salu2!

Hombre yo sí veo útil hacer DLLs para AutoIT cuando te encuentres una limitación que puedas subsanar por ahí (por ejemplo si para alguna cosa necesitas cálculo matemático de mayores prestaciones). Siempre que no sea más fácil hacer el programa completamente en el otro lenguaje, claro.

Pero no veo que vaya a ser más fácil hacer o adaptar código a DLLs en vez de hacerlo directamente en AutoIT, si se puede. Lo que hagas en la DLL no lo puedes controlar mucho en AutoIt, en la propia DLL tienes que controlar una serie de errores (a lo mejor por ahí va lo que dices de pasarle tipos de datos incorrectos), y en AutoIt otros...

Es más difícil de depurar, pues tienes que estar mirando el código en los dos lenguajes, y cuando falla igual no es tan fácil ver dónde está el problema, ¿en AutoIT? ¿en la DLL? ¿en la conexión entre ambos?

Ese problema que comentas te sirve de ejemplo. Para empezar yo haría un programa en VB (no AutoIt) que use la DLL, prueba a pasarle parámetros incorrectamente a ver qué tipo de error da. Intenta arreglar esos problemas en la DLL, para devolver un código de error... ¡porque el código de error lo tienes que devolver tú!
AutoIT puede darte un código de error en DLLCALL si por ejemplo no encuentra la DLL, pero si hay problemas internos en la DLL, (por ejemplo que le llega un número donde debería llegar una cadena) eso lo tienes que controlar tú en la DLL... y devolver el correspondiente código de error.

Lo dicho, lo de las DLL está muy bien, y amplía posibilidades, ¡pero no lo hace todo más sencillo! Así que si no es necesario... hazlo todo en AutoIt

Hola

Bueno, sí.

Tienes razón, en que lo que te soluciona por un lado te lo complica por otro.

Lo de encontrar errores, es cierto que es más difícil, y por supuesto, hay que valorar antes de hacer una dll, si realmente no será más sencillo hacerlo en AutoIt.

Cuando decía que podía ser más fácil para según qué, que habían cosas para las que se encontraba código para otros lenguajes con más facilidad que para AutoIt, me refería a cosas como por ejemplo el manejo de una dll complicada, como una que tratamos por aquí hace tiempo de Eloquence. La misma documentación tenía ejemplos para C++, de haber sabido hacer una dll en ese lenguaje, seguro que hubiera podido hacer una dll intermedia más sencilla, que la controlara (Un poco chapuza ¿Verdad?) pero es solo un ejemplo jejeje.
En ese caso, seguro que me hubiera resultado más fácil (nunca se sabe) encontrar errores de la dll hecha por mí, del programa de AutoIt, de la conexión entre ambos... que manejar la dichosa dll de Eloquence, que si no es por vosotros...

El problema del VB 6, es que parece que tampoco está muy pensado para hacer este tipo de dll's, porque con las cadenas es un lío.
Si en la dll convierto la cadena que va a devolver a Ascii, el AutoIt se cuelga, especifique el tipo de datos de retorno que especifique (lo normal entiendo que sería "STR"). Si no convierto la cadena desde la dll a Ascii, la función la devuelve como Unicode, y así tengo que recogerla con AutoIt ("WSTR") y funciona bien. Sin embargo, es imposible pasarle argumentos del tipo "String" a las dll hechas en VB 6.

Haré lo que dices, probar desde VB a llamar la dll, a ver que pasa, porque parece que no da problemas (tiene que ser cosa del AutoIt) y en concreto al especificar los tipos de datos, pero ya no se como hacerlo.

Salu2!