![]() |
Usar Formularios Base en Bpl estático
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, Cita:
Saludos, |
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 |
Cita:
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. En el segundo tienes un proyecto de ejemplo completo. La idea básica es esta: ![]() |
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. |
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. |
Cita:
|
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) |
Cita:
Cita:
Cita:
|
Cita:
Cita:
|
Ahora estoy mas claro,
Osea se ha agregado el archivo PkgForm0.dcp en las Opciones del proyecto Packages>Runtime Packages ademas de las unidades que se van a utilizar. Cita:
|
Cita:
Podrías evitar añadirlo al proyecto, aunque tendría que estar accesible, a través de las opciones del proyecto. Simplemente es una diferencia "visual". Igualmente como debe estar accesible, los usuarios podrían abrirlo y modificarlo. Simplemente que visulamente no se vería dentro del proyecto BPLFormTest. Cita:
No. La unidad está en el package y al hacer el USES de esa unidad, como el proyecto utiliza ese package, realmente está utilizando la unit almacenada en el package. Eso se ve fácil si revisas los recursos de cada fichero. Compila el package y compila el EXE y luego revisa los recursos de cada uno. Verás lo siguiente: ![]() ![]() Como puedes ver, el form0 está en el package, mientras que el form1 está en el EXE. Cita:
Al utilizar packages, se reduce el tamaño del EXE, o mejor dicho, lo que hacemos es "repartir" el tamaño que tendría un EXE único entre varios ficheros, en ese caso 1 EXE y N BPL's (más o menos). Eso es independiente de si los cargas de forma estática o dinámica. Las ventajas de la carga estática o dinñámica son otras, pero no afecta al tamaño final del proyecto. |
Excelente, ahora estoy mas claro.
Cita:
Perdón por la pregunta pero como puedo acceder al Resource Editor? Cita:
Muy agradecido de la orientación. Saludos, |
Cita:
Es una utilidad gratuíta de editor de recursos. la página es esta, aunque ahora mismo veo que no está disponible. http://melander.dk/reseditor/ De todas formas hay muchos otros programas similares, que a partir de un EXE o BPL te permiten ver los recursos que almacena. https://stefansundin.github.io/xn_resource_editor/ https://sourceforge.net/projects/xn-resource-editor/ https://alternativeto.net/software/xn-resource-editor/ https://alternativeto.net/software/resedit/ Añado uno más: https://www.mitec.cz/exe.html Y otro más: http://www.angusj.com/resourcehacker/ |
Perfecto,
Esas utilidades pueden ser de mucha ayuda para los que nos dedicamos a desarrollar aplicaciones. Gracias de Nuevo. ^\||/ |
La franja horaria es GMT +2. Ahora son las 12:10:25. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi