Usar Formularios Base en Bpl estático

[juniorSoft]

Hola de Nuevo amigos,

He visto varios Hilos donde nuestro amigo Neftali ha detallado como se puede desarrollar una aplicación realizando Plugins con Bpl, entre los que encontre:

INFO: DLL's, BPL's, carga dinámica, carga estática y Packages en Runtime

Unit común en proyecto con BPL's dinámicas.

Comunicacion entre BPL

En este caso lo que me interesa realizar es que todos los formularios base se encuentren en una BPL con el fin de que mis compañeros de trabajo no modifiquen dichos formularios para los proyectos, solo que puedan utilizarlos, con el fin de evitar modificaciones que traigan consigo errores en los demás proyectos.

El punto del que me gustaría ver un ejemplo es el siguiente,

* EXE + BPL carga estática(El EXE puede ser con o sin BWRP)
En este caso no hace falta definir nada referente a la función que se encuentra en el package, simplemente hacer referencia a ella en diseño.
Si el programa se compila con "BRWP Desactivado" TODO va dentro del EXE. Si se compila con "BWRP activado" la BPL va aparte, pero es obligatorio que exista, ya que la carga se ha hecho de forma estática (en diseño hemos añadido un USES); Si la BPL no existe el programa no puede funcionar.
Para trabajar así basta con añadir al USES las units del packages que necesitemos.

Y la pregunta es: para heredar de un formulario que se encuentre en la bpl cargada de forma estática, requiere utilizar RTTI para localizar los formularios utilizando el método GetClass o hay una forma mas fácil de realizar dicha tarea.

Saludos,

[[movorack]]

Hola.

Puedes colocar el padre de la herencia visual en un paquete Runtime, de esta manera la funcionalidad siempre la tomará del paquete base aunque modifiquen el aspecto de cada formulario heredado.

Un pequeño ejemplo

[Neftali [Germán.Estévez]]

Empezado por juniorSoft

Y la pregunta es: para heredar de un formulario que se encuentre en la bpl cargada de forma estática, requiere utilizar RTTI para localizar los formularios utilizando el método GetClass o hay una forma mas fácil de realizar dicha tarea.

Si estás heredando esos formularios desde un package que estás cargando estáticamnente, no hace falta RTTI, puesto que como el package que cargas depende y necesita en "base", puedes utilizar las units que necesites en el USES.

Si revisas estos artículos que hay en mi web, creo que es justo lo que necesitas. Un ejecutable con un paquete básico linkado de forma estática, que contiene la "clase base", para que luego otros packages cargados de forma dinámica la usen el anterior para hereder de las clases que contiene.

• Sistema de PlugIns en Delphi – Parte 1
• Sistema de PlugIns en Delphi – Parte 2

En el segundo tienes un proyecto de ejemplo completo.

La idea básica es esta:

[juniorSoft]

Gracias a ambos por contestar

El ejemplo de movorack es básicamente lo que andaba buscando aunque tiene un detalle que me gustaría aclarar:

En el Proyecto BPLFormTest la relación que tiene con el proyecto PkgForm0.dproj se da a través de usar la unidad UForm0 y esta unidad que es la que quiero proteger para que no sea modificada, esta agregada mediante la opción de menú project>add to project . y se puede modificar fácilmente. Lo que me gustaría es heredar pero impedir que modifiquen la unidades Base desde los proyectos descendientes.

Los ejemplos de Neftali son extensamente bien explicados y muy buenos, están mas enfocados en dividir en varios archivos los binarios resultantes para hacerlo modular de enganche y desenganche de módulos de la aplicación. Esto lo tengo como una tarea en agenda para mas adelante.

[[movorack]]

Si claro, se debe agregar al proyecto para que muestre correctamente el formulario hijo en diseño aunque la funcionalidad la toma de la BPL. Es decir que si después de compilado el programa modificas el comportamiento de la BPL, ej: Agregas un nuevo item al menú o modificas el comportamiento de algún item existente, el programa ya compilado deberá tomar el cambio de la BPL.

Una posibilidad (de varias) para que no modifiquen la unidad padre es que el grupo de desarrollo vea esa unidad desde un equipo remoto y tengan permisos de solo lectura.

[juniorSoft]

Si claro, se debe agregar al proyecto para que muestre correctamente el formulario hijo en diseño aunque la funcionalidad la toma de la BPL. Es decir que si después de compilado el programa modificas el comportamiento de la BPL, ej: Agregas un nuevo item al menú o modificas el comportamiento de algún item existente, el programa ya compilado deberá tomar el cambio de la BPL.

Partiendo de este punto ¿Que beneficios adicionales tendría con incluir estos formularios en un proyecto de paquete a diferencia de como lo tengo actualmente en el que los formularios base lo tengo en una carpeta separada en un proyecto VCL Form y los agrego al proyecto que se va a trabajar?.

[[movorack]]

Yo trabajo a diario de esta manera. te explico un poco, de pronto esto te de una idea.

En nuestro equipo tenemos un sin fin de ejecutables, casi que para cada funcionalidad. Es decir si habláramos de inventario, habría un ejecutable de parámetros, otro de categorías y elementos de inventario, otro de registro de movimientos, otro de los reportes y otro de cierre (y podrían haber mas... mucho mas).

Los formularios base se agregan a cada proyecto pero no se pueden modificar, el formulario principal de cada uno de estos programas hereda de estos base y al ejecutarse toman la versión que está en la BPL.

¿Que se obtiene en este caso? Los ejecutables tienen menor tamaño, comparten un mismo diseño y una misma funcionalidad y lo mas importante, cada vez que se modifica una funcionalidad compartida y que hace parte de la base solo debes cambiar la BPL y no re-compilar cada programa (Aunque aveces es necesario)