DLL ActiveX ó DLL Estandar

[Jad-Neo]

Mi pregunta es muy simple; ¿cuál es la mejor forma de crear librerías?, haciendolas ActiveX o estandar; cuales son las más eficientes (independientemente del lenguaje en el que estén escritas).

Esto es porque se crear de los dos tipos, pero no se cual es la mejor. Ojalá me puedan responder.

[GeoAvila]

bueno buscando una forma de explicarlo.. encontre esto..

Iniciado por Guille

No hace falta que te diga que no es lo mismo un EXE ActiveX que un EXE normal, por la sencilla razón de que si un EXE normal fuese lo mismo... desde hace tiempo que estaríamos creando componentes COM.
Igualmente no es lo mismo una DLL normal que una DLL ActiveX, ya que una DLL "normal" simplemente tiene funciones que podemos usar en nuestras aplicaciones, pero estas se usan directamente, sin la intervención de COM, tal es el caso de las DLLs del API de Windows las cuales podemos usar en cualquier programa. Por otro lado las DLL ActiveX son librerías que se pueden usar sólo con lenguajes que puedan trabajar con Automatización OLE (o COM).
Visual Basic está totalmente "adherido" a la automatización, es decir, entiende cómo crear objetos contenidos en componentes COM (de automatización) y, lo más importante, también puede crear componentes COM para que puedan ser usados desde otros lenguajes "adheridos" a la automatización.
Por tanto, Visual Basic podrá crear librerías (DLL) de automatización (componentes COM), pero no podrá crear librerías "normales".
Aclaro este punto, porque a pesar de que la extensión sea la misma para una librería normal y una de automatización, nuestro querido VB no podrá crear ficheros con la extensión DLL que se puedan usar de la misma forma que las librerías del API de Windows o las creadas por compiladores como C/C++ e incluso Delphi.

nos vemos..

[MaxExtreme]

Una librería dinámica (de las que estás hablando) sólo son "DLL". Las librerías ActiveX no son para nada normales ni las vas a poder usar en ningún lado. Ahora bien, las librerías DLL tampoco fuera de Windows.

Todo es cuestión de perspectiva. ActiveX es algo que ha muerto hace mucho tiempo, y no tiene sentido alimentarlo.

Una DLL normal con VB6 no la puedes hacer (si no es guarreando). Además, las DLL se usan para modularizar proyectos MUY grandes, donde cada componente se fabrica por separado, y sobre todo, para aliviar el tiempo de compilación.

Date cuenta que un proyecto grande puede tardar en compilar incluso horas, si se modulariza y se deja parte del código en DLLs, no hace falta re-compilarlo cada vez. Además, el control de versiones es mejor, y para hacer un sistema de plug-ins, también es muy interesante.

[GeoAvila]

y básicamente esto se llama reutiliazción de código, algo que le agradecemos a los lenguajes de 4a. generación y gracias a dios ya no es lineal, jaajaj

nos vemos..

[VisualGuallabo]

Iniciado por MaxExtreme

Una DLL normal con VB6 no la puedes hacer (si no es guarreando).

como dice max en Vb 6 se pueden crear dll normal(DLL DINAMICAS). pero engañando al compilador por llamarlo de alguna forma se pueden hacer.

Busca en la faq' que puse algo sobre el tema. hay encontraras link a otras web que tratan sobre el tema y a una utilidad que yo ise que te ahorra todo el trabajo del truco para engañar al compilador.

[Jad-Neo]

En conclusión, cual es la mejor forma de crear DLLs (estandar o ActiveX)?

[MaxExtreme]

Iniciado por Jad-Neo

En conclusión, cual es la mejor forma de crear DLLs (estandar o ActiveX)?

ActiveX: Es algo que está "muerto", nadie lo usa. Puedes usarlo, pero allá tú.

DLL: Bueno, cualquier lenguaje las podrá usar, y es algo que aprendido nadie te va a quitar, pero estamos en las mismas, no es "estándar". Es "estándar" para Windows.

¿Cuál es mejor?

Para mi, una librería estática (no DLL que es dinámica). Primero, porque es "portable" entre sistemas (al menos lo que aprendes te puede servir). Segundo, porque te evitas problemas en tiempo de ejecución.

Entre DLL y ActiveX, DLL sin duda.

[luciano]

Otra cosa es que las Dll ActiveX necesitan de la Runtime para poder funcionar

Saludos

Iniciado por MaxExtreme

ActiveX: Es algo que está "muerto", nadie lo usa. Puedes usarlo, pero allá tú.

DLL: Bueno, cualquier lenguaje las podrá usar, y es algo que aprendido nadie te va a quitar, pero estamos en las mismas, no es "estándar". Es "estándar" para Windows.

¿Cuál es mejor?

Para mi, una librería estática (no DLL que es dinámica). Primero, porque es "portable" entre sistemas (al menos lo que aprendes te puede servir). Segundo, porque te evitas problemas en tiempo de ejecución.

Entre DLL y ActiveX, DLL sin duda.

[MaxExtreme]

Iniciado por luciano

Otra cosa es que las Dll ActiveX necesitan de la Runtime para poder funcionar

Saludos

Ciertamente.

Pero aviso: Si se usa el truco para crear DLLs estándar con VB, siguen requiriendo el runtime. Si programas en VB, necesitas el runtime.

[[EX3]]

Iniciado por MaxExtreme

Una librería dinámica (de las que estás hablando) sólo son "DLL". Las librerías ActiveX no son para nada normales ni las vas a poder usar en ningún lado. Ahora bien, las librerías DLL tampoco fuera de Windows.

Ahi te contradices un poco, no? Siendo DLL, sea o no automatizada, oviamente fuera de Windows no iba a tirar, pero dentro de Windows tampoco? . . . Una DLL ActiveX sigue siendo una libreria dinamica, solamente que usa un metodo mas flexible para ofrecer formas de trabajo que una DLL Win32 no puede ofrecer, ademas, dime que lenguaje de los actuales para desarrollo sobre Windows, incluyendo los de la familia .NET, no soporta ActiveX?

Iniciado por MaxExtreme

Todo es cuestión de perspectiva. ActiveX es algo que ha muerto hace mucho tiempo, y no tiene sentido alimentarlo.

Me hace gracia que digas esto cuando el 90% de las aplicaciones de Windows se apoyan en esta tecnologia incluso en la actualidad, fijate que hasta Windows Vista soporta la tecnologia ActiveX.

Iniciado por Jad-Neo

En conclusión, cual es la mejor forma de crear DLLs (estandar o ActiveX)?

Todo depende de que quieres programar en la DLL y si te beneficia hacer una DLL para ello. Las diferencias a tener en cuenta es que una DLL Win32 no requiere registro en el sistema para poder funcionar pero por contra no permite desarrollar una interfaz de llamadas tan dinamica y flexible como permite un componente ActiveX. Ten en cuenta que lo unico en comun entre ambos metodos es que como bien ha dicho MaxExtreme ambas requieren de la runtime para funcionar, como cualquier otro programa compilado con Visual Basic.

Salu2...

[MaxExtreme]

Iniciado por [EX3]

Ahi te contradices un poco, no? Siendo DLL, sea o no automatizada, oviamente fuera de Windows no iba a tirar, pero dentro de Windows tampoco? . . . Una DLL ActiveX sigue siendo una libreria dinamica, solamente que usa un metodo mas flexible para ofrecer formas de trabajo que una DLL Win32 no puede ofrecer, ademas, dime que lenguaje de los actuales para desarrollo sobre Windows, incluyendo los de la familia .NET, no soporta ActiveX?

No me contradigo en nada. Una ActiveX no la vas a poder usar en C/C++/ estándar, por poner un ejemplo. Una DLL normal, sí (salvando usar LoadLibrary() claro).

PD: No soportan ActiveX, "arrastran" ActiveX.

Iniciado por [EX3]

Me hace gracia que digas esto cuando el 90% de las aplicaciones de Windows se apoyan en esta tecnologia incluso en la actualidad, fijate que hasta Windows Vista soporta la tecnologia ActiveX.

¿90%? Hum... No sé dónde has visto eso (no creo que sea verdad, pero tampoco me creo que el "90%" use tales cosas), o al menos, no las necesitan. Los programas Linux&Windows (que cada vez son más), no lo usan, y no veo la necesidad de usarlo: OpenOffice, gcc, Mozilla, Firefox...

Iniciado por [EX3]

Todo depende de que quieres programar en la DLL y si te beneficia hacer una DLL para ello. Las diferencias a tener en cuenta es que una DLL Win32 no requiere registro en el sistema para poder funcionar pero por contra no permite desarrollar una interfaz de llamadas tan dinamica y flexible como permite un componente ActiveX. Ten en cuenta que lo unico en comun entre ambos metodos es que como bien ha dicho MaxExtreme ambas requieren de la runtime para funcionar, como cualquier otro programa compilado con Visual Basic.

Salu2...

ActiveX es bastante "cutre" y las especificaciones y críticas que se le han hecho... Junto con OLE y demás bobadas. Por otra parte, una DLL normal puede ser cargada "fácilmente" en Linux.

Que quede claro, una DLL normal no requiere el runtime (si la has programado sin VB claro, lo que es lo normal).

[[EX3]]

Iniciado por MaxExtreme

No me contradigo en nada. Una ActiveX no la vas a poder usar en C/C++/ estándar, por poner un ejemplo. Una DLL normal, sí (salvando usar LoadLibrary() claro).

Estas seguro de esto que acabas de decir? Si? Te animo a que lo compruebes y luego me cuentes Estandar o no si estas programando C++ en Windows tambien puedes usar componentes ActiveX. No se si sabes que mediante LoadLibrary() tambien se puede acceder a las funciones de un componente ActiveX.

Iniciado por MaxExtreme

¿90%? Hum... No sé dónde has visto eso (no creo que sea verdad, pero tampoco me creo que el "90%" use tales cosas), o al menos, no las necesitan. Los programas Linux&Windows (que cada vez son más), no lo usan, y no veo la necesidad de usarlo: OpenOffice, gcc, Mozilla, Firefox...

Creetelo o no pero es asi. La tecnologia ActiveX es una tecnologia que se ha explotado mucho en el desarrollo de aplicaciones Windows incluso a dia de hoy. La inmensa mayoria de los programas que corren en tu ordenador funcionan con ella. Y sobre eso de que los programas Linux&Windows cada vez son mas... sin comentarios, mejor no entro en detalles.

Iniciado por MaxExtreme

ActiveX es bastante "cutre" y las especificaciones y críticas que se le han hecho... Junto con OLE y demás bobadas. Por otra parte, una DLL normal puede ser cargada "fácilmente" en Linux.

Cutre no creo, incomoda por que tengas que registrar el componente y demas, ahi si te daria la razon, pero si me dieses a elegir un sistema u otro me quedo con el ActiveX, mas amigable de usar y como dije antes mas flexible. Por cierto, Winex tambien carga componentes ActiveX, con el mismo exito aproximado que con las DLL's Win32.

Iniciado por MaxExtreme

Que quede claro, una DLL normal no requiere el runtime (si la has programado sin VB claro, lo que es lo normal).

Y una DLL ActiveX programada en C++ o Delphi tampoco requiere runtime.

Me da que simplemente le tienes asco o tirria al tema de los componentes ActiveX y que eso te ciega para hablar del tema, por que casi todo lo que has dicho o eran verdades a medias o no eran ciertas.

Salu2...

[MaxExtreme]

Pese a que trates de maquillar a ActiveX, es algo tecnológicamente muy lejos de lo que podamos llamar "estándar", mucho más que una DLL normal de Windows.

Sobre lo de aplicaciones Linux, no veo por qué no quieres dejar comentarios.

Sobre lo del uso de la librería ActiveX, me parece absurdo utilizar ActiveX para luego usarla como una DLL normal.

[[EX3]]

Iniciado por MaxExtreme

Pese a que trates de maquillar a ActiveX, es algo tecnológicamente muy lejos de lo que podamos llamar "estándar", mucho más que una DLL normal de Windows.

ActiveX lo soporta cualquier version de Windows, sin modificaciones ni añadidos, lo puedes desarrollar en una version u en otra que sera totalmente compatible. Lo soporta C++, VB, Delphi y varios lenguajes mas. Puedes desarrollar un componente ActiveX en cualquier lenguaje de los citados que sera soportado por todos ellos. Eso es estandar.

Iniciado por MaxExtreme

Sobre lo del uso de la librería ActiveX, me parece absurdo utilizar ActiveX para luego usarla como una DLL normal.

Esque el uso no es el mismo que el de una DLL Win32. Una DLL ActiveX es lo mismo que un OCX solo que sin interfaz grafica. Puede contener objetos con sus metodos, funciones, propiedades y estructuras de datos propias, cosa que una DLL Win32 no.

En el fondo lo que esta claro es que para 4 funciones sencillas no vas a montar una DLL ActiveX ya que es como matar moscas a cañonazos. Oviamente en ese caso elgiria sin duda montar una DLL Win32. Para cosas mas extensas, que pudieras necesitar mas flexibildad por ejemplo, mediante objetos de los que pudieras instanciar tantas copias como necesitaras por ejemplo para organizar mejor el trabajo, pues oviamente un componente ActiveX es mas comodo.

Salu2...

[VisualGuallabo]

Lo que no hay duda es que las ocx son muy cómodas, si no hubiera que registrarlas serian mas eficaces.
IMAGINENCE.

DLLACTIVE Y OCX :Pueden Tener Interfaz, objetos con acceso a sus propiedades , funciones y métodos. también puede estar formada por funciones y procedimientos al igual que la dll Dinámica.

DLL DINAMICA :estar formada por funciones y procedimientos.

¿si dll Axtive y ocx no se registraran que prefieren las mencionados o a las
d.C. dinámicas?
Creo que eso no se pregunta.
Mi respuesta final es que cada una tiene su objetivo y su función, al igual el lápiz es para escribir y la goma para borrar.

Las ocx, dll Activex y las dll dinámicas son WIN32 al igual que los exe siempre y cuando sean de Windows 32 BIT.

para referirse a las dll nómbrelas según su tipo por que todas son win32 ya que son de Windows 32 BIT.
Dll dinámica
dll activeX
DLL ESTATICA.

[MaxExtreme]

Iniciado por [EX3]

ActiveX lo soporta cualquier version de Windows, sin modificaciones ni añadidos, lo puedes desarrollar en una version u en otra que sera totalmente compatible. Lo soporta C++, VB, Delphi y varios lenguajes mas. Puedes desarrollar un componente ActiveX en cualquier lenguaje de los citados que sera soportado por todos ellos. Eso es estandar.

Esque el uso no es el mismo que el de una DLL Win32. Una DLL ActiveX es lo mismo que un OCX solo que sin interfaz grafica. Puede contener objetos con sus metodos, funciones, propiedades y estructuras de datos propias, cosa que una DLL Win32 no.

En el fondo lo que esta claro es que para 4 funciones sencillas no vas a montar una DLL ActiveX ya que es como matar moscas a cañonazos. Oviamente en ese caso elgiria sin duda montar una DLL Win32. Para cosas mas extensas, que pudieras necesitar mas flexibildad por ejemplo, mediante objetos de los que pudieras instanciar tantas copias como necesitaras por ejemplo para organizar mejor el trabajo, pues oviamente un componente ActiveX es mas comodo.

Salu2...

Casi nada de Windows es estándar salvo para él mismo, es a lo que me refería. Veo más "normal" una DLL que otra ActiveX. Que por cierto, C++ no soporta ActiveX ni las DLLs normales, otra cosa es el compilador. En cambio en VB diría que es algo innato del lenguaje.

¿Cómo que una DLL Win32 no puede contener métodos, funciones, clases y estructuras? Puedes exportar cualquier de esas cosas, creo que te referirás a los objetos tipo ActiveX, auto-manejados.

[MaxExtreme]

Iniciado por VisualGuallabo

Lo que no hay duda es que las ocx son muy cómodas, si no hubiera que registrarlas serian mas eficaces.
IMAGINENCE.

DLLACTIVE Y OCX :Pueden Tener Interfaz, objetos con acceso a sus propiedades , funciones y métodos. también puede estar formada por funciones y procedimientos al igual que la dll Dinámica.

DLL DINAMICA :estar formada por funciones y procedimientos.

¿si dll Axtive y ocx no se registraran que prefieren las mencionados o a las
d.C. dinámicas?
Creo que eso no se pregunta.
Mi respuesta final es que cada una tiene su objetivo y su función, al igual el lápiz es para escribir y la goma para borrar.

Las ocx, dll Activex y las dll dinámicas son WIN32 al igual que los exe siempre y cuando sean de Windows 32 BIT.

para referirse a las dll nómbrelas según su tipo por que todas son win32 ya que son de Windows 32 BIT.
Dll dinámica
dll activeX
DLL ESTATICA.

Incorrecto, las DLL Win32 pueden contener clases, métodos, funciones y lo que quieras. Es, salvando distancias, lo mismo que un .exe.

Ni tampoco existen "DLL estáticas"... Te has confudido con las liberías estáticas que mencioné antes.

[[EX3]]

Iniciado por MaxExtreme

Casi nada de Windows es estándar salvo para él mismo, es a lo que me refería. Veo más "normal" una DLL que otra ActiveX. Que por cierto, C++ no soporta ActiveX ni las DLLs normales, otra cosa es el compilador. En cambio en VB diría que es algo innato del lenguaje.

Dejemoslo en que VB es una chapuza, que en eso seguro que estamos deacuerdo ambos xDD

Iniciado por MaxExtreme

¿Cómo que una DLL Win32 no puede contener métodos, funciones, clases y estructuras? Puedes exportar cualquier de esas cosas, creo que te referirás a los objetos tipo ActiveX, auto-manejados.

Resumidamente, una DLL Win32 (o DLL "normal" como tu la clasificas) no, una DLL que use o implemente una interfaz COM si, y un componente ActiveX es un objeto que se basa en interfaces COM.
Un ejemplo serian las DLL's que componen el API de DirectX, son todas DLL's que implementan interfaces COM pero no llegan a ser componentes ActiveX. Un ActiveX lo que permite es interactuar entre varios objetos, programar sistemas cliente/servidor (en realidad es uno de los propositos para lo que se diseño) que permitan varias instancias de un mismo objeto en un mismo sistema de forma simultanea.

Iniciado por MaxExtreme

Las ocx, dll Activex y las dll dinámicas son WIN32 al igual que los exe siempre y cuando sean de Windows 32 BIT.

para referirse a las dll nómbrelas según su tipo por que todas son win32 ya que son de Windows 32 BIT.
Dll dinámica
dll activeX
DLL ESTATICA.

No seria tampoco correcta esa definicion. Cierto es que Win32 seria todo aquel programa basado y desarrollado para funcionar en plataformas Windows de 32 bits, pero decir que una DLL "normal" es estatica es un error (error que hace un tiempo cometia igual al referirme a ellas) Seria mas correcto decir "Librerias no automatizadas", aunque la defincion de DLL Win32 sigue siendo igual de valida para diferenciarla de una DLL ActiveX.


Salu2...

[MaxExtreme]

Iniciado por [EX3]

Dejemoslo en que VB es una chapuza, que en eso seguro que estamos deacuerdo ambos xDD

Resumidamente, una DLL Win32 (o DLL "normal" como tu la clasificas) no, una DLL que use o implemente una interfaz COM si, y un componente ActiveX es un objeto que se basa en interfaces COM.
Un ejemplo serian las DLL's que componen el API de DirectX, son todas DLL's que implementan interfaces COM pero no llegan a ser componentes ActiveX. Un ActiveX lo que permite es interactuar entre varios objetos, programar sistemas cliente/servidor (en realidad es uno de los propositos para lo que se diseño) que permitan varias instancias de un mismo objeto en un mismo sistema de forma simultanea.

No seria tampoco correcta esa definicion. Cierto es que Win32 seria todo aquel programa basado y desarrollado para funcionar en plataformas Windows de 32 bits, pero decir que una DLL "normal" es estatica es un error (error que hace un tiempo cometia igual al referirme a ellas) Seria mas correcto decir "Librerias no automatizadas", aunque la defincion de DLL Win32 sigue siendo igual de valida para diferenciarla de una DLL ActiveX.


Salu2...

Sí, VB es bastante desastroso como comentaba al mismo tiempo en el otro post. Pero ayuda a los novatos a conocer la programación, eso también ha sido bueno. Aunque dicen que después de todo quien aprende VB está perdido (o casi) para poder aprender otro lenguaje después.

Las librerías estáticas sí pueden exportar cualquier cosa "class juanito : public pepito" (no un objeto COM es a lo que me refiero). Y una DLL Win32, en teoría no soporta todas las cosas que se puedan hacer en C++ (no recomendaban usar templates en ellas, o pasar punteros entre la DLL y el programa que la carga, etc).

PD: Eso último era una quote de VisualGuallabo XD, lo cual ya le había corregido antes.

[[EX3]]

Iniciado por MaxExtreme

Sí, VB es bastante desastroso como comentaba al mismo tiempo en el otro post. Pero ayuda a los novatos a conocer la programación, eso también ha sido bueno. Aunque dicen que después de todo quien aprende VB está perdido (o casi) para poder aprender otro lenguaje después.

El problema del BASIC en general es que se aleja de la sintaxis de C y de lenguajes similares. Lenguajes como Pascal ayudan mas a entrar luego en grandes como C/C++ por muchas similitudes en su forma de programar. Pero vamos, sabiendo programar en un lenguaje, sea el que sea, aprender otro no es mucho problema, total, la metodologia de programacion y estructuras basicas de control las tienen todos y eso es suficiente para sumergirte en nuevos lenguajes :)

Salu2...

[MaxExtreme]

Iniciado por [EX3]

El problema del BASIC en general es que se aleja de la sintaxis de C y de lenguajes similares. Lenguajes como Pascal ayudan mas a entrar luego en grandes como C/C++ por muchas similitudes en su forma de programar. Pero vamos, sabiendo programar en un lenguaje, sea el que sea, aprender otro no es mucho problema, total, la metodologia de programacion y estructuras basicas de control las tienen todos y eso es suficiente para sumergirte en nuevos lenguajes :)

Salu2...

Un "if" será siempre un "if". Pero vamos al "for", y en VB la sintaxis ya es mala.

Pero en C tienes sintaxis bastante más compleja que VB. En cambio, C++, la sintaxis es ... (pon el adjetivo que mejor describa una exageracion). Es decir, C tiene "if" "for" "while" igual que VB, pero por ejemplo, aritmética de punteros, fundamental: Alguien de VB no la sabe.

Y hablando de cosa de C++, impensable. Un tipo de VB6 no sabe que es una clase, un árbol, una lista enlazada, una plantilla, un puntero, una herencia, un casting, un header, un ... etc. Son muchas cosas a aprender.

Ahora claro, como dices, siempre podremos programar en "C++" usando "if", "for", "while" de siempre y nada más.

[[EX3]]

Iniciado por MaxExtreme

Pero en C tienes sintaxis bastante más compleja que VB. En cambio, C++, la sintaxis es ... (pon el adjetivo que mejor describa una exageracion). Es decir, C tiene "if" "for" "while" igual que VB, pero por ejemplo, aritmética de punteros, fundamental: Alguien de VB no la sabe.

Y hablando de cosa de C++, impensable. Un tipo de VB6 no sabe que es una clase, un árbol, una lista enlazada, una plantilla, un puntero, una herencia, un casting, un header, un ... etc. Son muchas cosas a aprender.

Yo me referia a que todos los lenguajes comparten los metodos de estructuras de control basicas, yo no calificaria los punteros o las clases si quiera de estructuras de control basicas. Estructuras de control basicas son las sentencias de decision if/then y select case, bucles while, etc... sabiendo lo basico se puede aprender todo lo demas, simple metodologia.

Salu2...

P.D.: Modula2 no soporta punteros ni clases por ejemplo y sin embargo se utiliza en muchos sitios como lenguaje para enseñar lo basico de la programacion. Con el se da el salto a Pascal, C/C++, VB y cualquier lenguaje que se te ocurra.

[MaxExtreme]

Iniciado por [EX3]

Yo me referia a que todos los lenguajes comparten los metodos de estructuras de control basicas, yo no calificaria los punteros o las clases si quiera de estructuras de control basicas. Estructuras de control basicas son las sentencias de decision if/then y select case, bucles while, etc... sabiendo lo basico se puede aprender todo lo demas, simple metodologia.

Salu2...

P.D.: Modula2 no soporta punteros ni clases por ejemplo y sin embargo se utiliza en muchos sitios como lenguaje para enseñar lo basico de la programacion. Con el se da el salto a Pascal, C/C++, VB y cualquier lenguaje que se te ocurra.

Claro, todo es metodología, pero creo que aprender qué es la herencia y cómo usarla cuesta bastante más que entender lo que es un "if".

Hay muuuuucho más por aprender que sentencias básicas "y algo más".

Y sí, los punteros son _básicos_ en lenguajes como C. En C++ puedes (si no estás haciendo algo raro) omitirlos usando referencias, al igual que en muchos otros lenguajes, y usando clases que abstraen el uso de la memoria, pero, al final, se usan.

[[EX3]]

Si yo puede aprender el uso de punteros, programacion orientada a objetos con su herencia y poliformismo y demas elementos de un lenguaje de verdad como C++ despues de 3 años programando enteramente en VB6 y antes 2 años de GW-BASIC (mas arcaico si puede ser) cualquiera puede. Aprender cualquier cosa es dificil al principio pero teniendo una base minima de lo basico y que es lo general en todos los demas lenguajes el resto es ponerse con ello simplemente. Eso es asi con todo.

Salu2...

[Jad-Neo]

Bueno, esto puede seguir y nunca terminar el tema. La cosa está en que no importa si es un DLL ActiveX, DLL estática o DLL Dinamica, todas cumplén con su función (no importando su arquitectura o forma de trabajar).

Finalmente me decidí (por medio de la discusión en este tema) que si se quieren crear DLLs en VB no más para procedimientos (sin incluir clases), la DLL estandar (con APIs) es la mejor opción; dado que no necesita registrarce para usarla, sólo basta con usar Declare.

Ahora, si se quieren crear clases con referencias a objetos y manejo de eventos, la DLL ActiveX sería lo mejor. Dado que aún trucando VB para exportar APIs en una DLL, tiene serios problemas con manejo de objetos de la misma runtime (ej. App.Path ó hasta Dir).