FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
como se usan las dll en otro Proyecto
tengo una aplicacion como dll1, luego llamo a otro proyecto, como hagoo para usar la dll1, para usar todos los formularios del mismo
|
#2
|
|||
|
|||
si no me hice entender diganme please
|
#3
|
|||
|
|||
Bueno, te diré lo que entendí:
Tienes encapsulados en una DLL varios formularios, para poderlos cargar dinámicamente desde otro programa ¿es esto correcto? Básicamente debes tener definida en el proyecto dll1 (la .DLL) una función al menos por cada formulario que quieras lanzar, de forma que la aplicación externa llame a esa función simplemente. Dicha función (o procedure, da igual) deberá tener un parámetro AHandle del tipo THandle, para que la aplicación Host le pase en dicho parámetro Handle del Form principal, es decir Application.Handle; de esta forma los formularios llamados se comportarán como hijos de tu programa (eso sí, claro, cuando los crees en la DLL haz esto Form1 := TForm1.Create (AHandle) ). Por lo demás, supongo que sabes las convenciones de llamada para este tipo de funciones, y cómo debes llamarlas, aquí te pongo un ejemplito : Código:
function TDATAMAIN.IniciaAsistenteConexion (NumCon: Smallint) : Boolean; var LibHandle : THandle; CWizard : TShowConnectWizard; begin result := FALSE; LibHandle := LoadLibrary(NomDLLDialogos); try if LibHandle = 0 then raise EDLLLoadError.Create('No se pudo cargar la DLL'); @CWizard := GetProcAddress(LibHandle, 'ShowConnectWizard'); result := (@CWizard <> nil); if result then result := CWizard (Application.Handle, TRUE, NumCon, DirAplicacion, NomArchivoIni, SolicitaCerrarSesion) else RaiseLastWin32Error; finally FreeLibrary(LibHandle); end; end; TShowConnectWizard en este caso es un tipo de función que concuerda con una función implementada en la DLL, en esta rutina lo que se hace es colocar en la variable CWizard una referencia a dicha función de la DLL (GetProcessAddress), si es que se encuentra. Esto es una forma dinámica de hacer las cosas, normalmente se sabe de antemano el nombre de la función y se fija por código al compilar (fíjate en la unit Windows que viene con Delphi, ahí se declaran muchas funciones que son referencias a funciones en DLLs de Windows y coinciden hasta con el mismo nombre). Finalmente, si se encontró la función deseada, se la llama, pasándole como primer parámetro el Application.Handle que te comenté más arriba. Si quieres hacer pruebas de la DLL, teniendo el proyecto Dll1 activo en el IDE de Delphi, vas al menú Run - Parameters y ahí le indicas cuál es la aplicación host (tu otro proyecto compilado). Espero que ahora lo tengas más claro, no sea que te lo haya complicado más aún. Saludos
__________________
Guía de Estilo |
#4
|
|||
|
|||
como me recomiendas q haga...
para hacer varias aplicaciones... en VB hago cada aplicacion como dll y luego desde otro proyecto voy llamando las aplicaciones por medio de las dll. Esto con el fin de no tener un proyecto con todas las aplicaciones porque serial despues el Exe muy grande e incontrolable para el manejo de la aplicacion. Ahora en Delphi como es el Funcionamiento es igual dll ó estuve leyendo de las DCP q creo q es con eso... necesito q me orienten gracias. muchas gracias por la explicacón anterior... |
#5
|
|||
|
|||
Puedes hacerlo de varias maneras (si no lo queieres todo en un programa)
1.- Hacerlo en dll (como lo hacias en VB) 2.- Hacer bpl (parecido a las dll) 3.- Hacer ejecutables y llamadas a estos desde la app principal Tu eliges. Depende de lo que mas te guste o mas facil te sea |
#6
|
|||
|
|||
muchas gracias pero como las unooo esa es la preguntaa en la principal
USES Nombre de la dll o de la dcp y listoo o como es... |
#7
|
|||
|
|||
por ejemplo, una llamada completa a una dll
**** programa principal (o llamador) Código:
unit tal; interface uses .... type .... end; //del type Const MyDll = 'MyDll.dll'; var MyFunctionInDll : function ( hWnd : THandle;....): Integer stdcall; implemantation uses..... procedure TMyForm.Button1Click(Sender: TObject); var Handle: THandle; begin Handle := LoadLibrary(MyDll); if Handle <> 0 then begin @MyFunctionInDll := GetProcAddress(Handle, 'MyFunctionInDll'); try if @MyFunctionInDll <> nil then begin MyFunctionInDll ( Self.Handle, .....); end; finally FreeLibrary(Handle); end; end; // Fin del IF del Han end; Código:
library MyDll; uses ..... function MyFunctionInDll ( hWnd : THandle; .....) : integer; stdcall; export; var iValRet: Integer; begin Application.Handle := hWnd; MyFormInDll := TMyFormInDll.Create(Application); try iValRet := MyFormInDll.ShowModal; finally FreeAndNil(MyFormInDll); end; Result := iValRet; end; exports MyFunctionInDll; begin end. |
#8
|
|||
|
|||
Hola a todos
Soy nuevo en Delphi, vengo de VB6 y un tiempo en C# pero VS.NET no me parecio adecuado por la inestable comunicacion con Bases de Datos distintas SQL Server y MS Access y muy pesado el deployment. Al final Delphi me parecio una excelente herramienta y aqui estoy. Hago esta aclaratoria porque es muy probable que haga muchas preguntas que a Uds les pareceran muy estupidas. Aqui va la primera. En una respuesta anterior explicaban la posibilidad de trabajar con una DLL o un Package, quisiera saber de acuerdo a vuestras experiencias cual es la mejor o si cada una tiene aplicaciones especificas. Pero la pregunta especificamente es para el caso en que la DLL tiene encapsulado el funcionamiento de una Apliacion, y un pequeno programa se encarga de las llamadas a las diferentes DLLs de cada Aplicacion. Gracias de antemano, Saludos, |
#9
|
||||
|
||||
En particular, creo que es mucho mas fácil trabajar con BPL´s, y sólo utilizaría DLL´s para compatibilizar mis aplicaciones con otros lenguajes que no sean Delphi y/o Borland C++ o alguna aplicación muy específica donde priorize otros temas.
La gran ventaja con las BPL´s es que no tienes que desarrollar todo ese "protocolo" interno para que tu aplicación se "comunique" con la DLL, puedes compartir clases como si estuvieras programando una sola aplicación, salvo que quieras cargar los paquetes en forma dinámica. Les recomiendo leer este link: http://www.clubdelphi.com/foros/show...ht=MODULARIZAR Saludos!
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. |
#10
|
|||
|
|||
Otra ventaja de usar BPLs es que, con esta filosofía, las definiciones de clases y la información de tipos en tiempo de ejecución (RTTI) está localizada en un solo lugar, el package, mientras que el uso de DLLs comporta que se repita esa información (en la DLL y en nuestra aplicación), pudiendo dar origen a multitud de errores cuando se hacen comprobaciones de tipo (ejemplo los operadores is y as). Por ello, cuando se desarrollan DLLs con Delphi para ser usadas por un programa en Delphi, se recomienda que ambas sean compiladas usando paquetes en tiempo de ejecución. Claro que esto es un tanto ridículo.
Y como en casa del herrero, cuchillo de palo, el ejemplo que puse al principio de este hilo, pertenece a un programa donde me salto a la torera todos estos consejos, quizás porque ví que no utilizaba instrucciones peligrosas, pero es aconsejable usar los BPL para estos menesteres. Saludos
__________________
Guía de Estilo |
#11
|
|||
|
|||
muchas gracias por sus concejos dados
desde ayer estoy intentado agregar una bpl pero no he podido, por casualidad no tienen un ejemplo de como hacerlo... integrarlo a un exe normal. Se lo agradesco muchas gracias.... |
#12
|
||||
|
||||
Bueno pues buscando info sobre DLL en el foro, pienso que puedo poner mi duda aqui y es la siguiente:
Ahora Debido a que estamos programando modularmente, seria meter esas lineas en cada programa, trasteando en el delphi y buscando algo que se pareciera al VB6 en esta cuestión, trate:
|
|
|
|