FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
creacion y ejecucion de bpl
buenos dias
estoy creando una bpl (File... New...Package - Delphi) ahi he agregado un formulario donde muestro una relación de artículos (Alojadas en un servidor) entonces la unidad se esta llenando de algunos formularios adicionales formulario para mostrar los trabajadores (frmCatalodoArticulos_f.pas + dfm) formulario para el CRUD de los trabajadores (frmCatalodoArticulosD_f.pas + dfm) datamodule (para la conexion a la base de datos) (dmGlobal.pas) archivo de librerias para algunas funciones (_Librerias.pas) compilo y me genera mi Archivo Articulos.bpl (Genial, listo... dije.. uf... ya esta..) la pregunta del millon es... como hago para utilizarlo? he estado revisando ejemplos https://neftali.clubdelphi.com/dlls-...es-en-runtime/ pero como que no los he entendido muy bien pienso porque lo he leido (y si me equivoco me corrigen) que una bpl es una dll pero exclusiva para delphi, que sirve para entre otras cosas aislar ciertas funciones que pueden ser repetitivas y que podrian utilizarse en cualquier otra aplicación del entorno de desarrollo delphi. ahora viene el meollo estoy creando una aplicación nueva y quiero utilizar esa librería para llamar a ese formulario otra pregunta que me surje es... dentro de ese bpl he incluido algunos otros formularios que son "de uso comun", como por ejemplo un form donde me muetra un gauge al momento de imprimir o importar informacion, esos formularios "de uso comun" como los puedo utilizar? si creo mas bpl (para generar visualmente otros CRUD o mantenimientos) podria incluir una bpl dentro de otra? para la utilizacion de estos formularios de uso comun? alguien tiene ejemplos o ideas? se los agradecere
__________________
Dulce Regalo que Satanas manda para mi..... |
#2
|
||||
|
||||
Hola, de pronto este pequeño ejemplo te sirva de algo.
https://bitbucket.org/mivaler/delphi...rm-into-a-bpl/
__________________
Buena caza y buen remar... http://mivaler.blogspot.com |
#3
|
||||
|
||||
disculpa la ignorancia...
donde invocas al bpl ? porque lo que veo (salvo me equivoque) es que estas invocando a un form (que tambien esta en una bpl)
__________________
Dulce Regalo que Satanas manda para mi..... |
#4
|
||||
|
||||
En el ejemplo que te dí, la BPL como tal no la invocas.
Es decir, no la inicializas como a una dll
En ese ejemplo se usa en el proyecto como una unidad mas y como se compilas con la opción "Link with runtime packages", en "Runtime packages" está establecido que cargará la BPL PkgForm0 en tiempo de ejecución. Lo que hace que el ejecutable generado no contenga el formulario del cual se hereda sino que esté dentro de la BPL. Para tu caso, puedes agregar un formulario en una BPL y solo usarlo, como lo harías normalmente.
Tip: Puedes establecer que en Debug, no use los paquetes en tiempo de ejecución. Eso te ayuda a modificar la BPL y realizar las pruebas antes de generar el paquete completo para release
__________________
Buena caza y buen remar... http://mivaler.blogspot.com |
#5
|
||||
|
||||
Lo primero que necesitamos saber es si quieres utilizarlos:
(1) Con carga estática (esto sería lo normal) (2) Con carga dinámica Si es el caso (1) que sería el normal, basta con utilizar las units a modo normal (USES). Cita:
En la entrada tienes ejemplos de todos los casos. ¿Los has revisado? En cada uno de ellos está como utilizar las BPL's/DLL's Cita:
A veces pueden servir simplemente para organizar ficheros de un proyecto muy grande, para reutilizar código/funciones/formularios entre diferentes proyectos, para crear componentes,... Depende de la primera pregunta. Si quieres (1) o (2) Cita:
Si te refieres a usar cosas de una BPL desde otra BPL, SI. Sin problemas. Igual que desde un EXE puedes usar cosas de una BPL o de una DLL.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#6
|
||||
|
||||
Cita:
creo que estatica seria lo mas apropiado la idea que tengo es la siguiente: 1.- tratar de reducir el tamaño del ejecutable 2.- Reutilizar los catalogos (mantenimientos de tablas principales, llamese clientes, articulo, almacenes, etc en otras aplicaciones) todos sabemos que los formularios por la funcionalidad muchas veces no estan solos, se les agrega otros formularios externos (como por ejemplo ver los precios de un articulo en otra ventana), entonces al crear el bpl obvio que tengo que adjuntar ese formulario adicional, que tambien puedo utilizarlo de manera individual )desde otra opcion), la pregunta es.. como invocarlo? suficiente con colocar uses en la unidad? osea un uses articulo.bpl ??? espero haberme explicado bien
__________________
Dulce Regalo que Satanas manda para mi..... |
#7
|
|||
|
|||
Hola a todos!!
¡¡Tema muy interesante!! Quizás el problema que nos encontramos cuando empezamos a ver el potencial de las BPLs es imaginar que esto funciona como los plugins que vemos en navegadores o en aplicaciones webs, por ejemplo un plugin de prestashop, donde lo instalas y de golpe añade un montón de funcionalidades nuevas a cualquier parte de la aplicación web y claro no es tan fácil ... Aquí dejo un enlace a un ejemplo de "PLUGIN" externo, que inserta un menú al formulario principal de la aplicación. Si se quieren usar varios "plugins" habría que aplicar un método de combinación de los menús de los distintos plugins para crear un único menú principal. Aunque con las BPL se puede conseguir cosas interesantes, me he encontrado con limitaciones importantes que después de darle muchas vueltas, aun intento ver como solucionar. Uno de estos temas pendientes, por si alguien puede dar una solución es como utilizar las variables "globales" guardadas en las BPLs. En el ejemplo que he subido, la variable "dato" de la unidad plugins, es una de estas variables globales, la comparte la aplicación, y el plugin externo, pero en realidad en memoria son dos variables totalmente distintas, una para la aplicación y otra para el plugin, por que cuando el form del plugin modifica o guarda ese dato, la aplicación lo que lee es otra cosa totalmente distinta. A esto creo que es lo que se refiere oscarac: Cita:
|
#8
|
||||
|
||||
Cita:
Tal y como tienes planteado el ejemplo, tienes definida la variable Dato en el "plugin base" (plugins.pas). Esto hace que la compilación te funcione correctamente, pero es lógico que al cargar el plugin en ejecución y crear el formulario esa variable quede vacía. Estás accedeiendo realmente a otra posición de memoria. Creo que es mucho más fácil que eso; Ya que tienes montada toda la estructura para cargar los plugins, crear los formularios y mantenerlos. Pues utilizala para guardar la información que necesites. Desde el programa principal tienes una lista que almacenas plugins Creados/Cargados (ListBPL). Y además ya tienes creada una estructura que almacena datos (TPluginInfo) para cada pluging. Utilizala para almacenar lo que necesites y no tendrás problemas en acceder a esa información. Te adjunto el ejemplo con una líneas modificadas para explicar lo que quiero decir.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#9
|
||||
|
||||
Cita:
En el caso de (1) ten en cuenta que reducirás el tamaño del fichero EXE, pero a cambios deberás distribuir el EXE y algunos ficheros BPL. Es posible que al final la suma de tamaños de los BPL y el EXE sea igual o ligeramente superior al EXE original. Esto hay que tenerlo claro. En el caso de (2) es correcto. Utilizar BPL's, si están bien organizados, tiene ventajas. Una de ellas la que comentas, podrás reutilizar elementos en diferentes proyectos. Cita:
El USES de la unidad (articulos) no del package (articulo.bpl). Como lo harías con cualquier otra unidad del proyecto. Siempre que estés utilizando carga estática, como comentas, las units de los packages a efectos del IDE son iguales que las del proyecto principal. Siempre que estén accesibles para el IDE (que el IDE conozca el directorio donde se encuentran) no debes hacer nada diferente. Añadir el nombre de la unit al USES, como siempre.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#10
|
||||
|
||||
quiero entender muy bien el proceso y la funcionalidad
a ver vamos por partes.... genero el bpl (se crea un archivo llamado articulo.bpl) - dentro esta: frmArticulo_f.pas frmavance_f.pas frmimportar_f.pas con sus correspondientes dfm luego otro archivo mas de recursos librerias.pas el datamodule dmGlobal.pas etc... Cita:
como sabe el IDE que va a cargar el archivo frmarticulo_f.pas o articulo.bpl (que lo contiene) imaginemos que quiero implementar una aplicacion nueva File... New... Vcl form Applications agregamos un form (que sera el principal) agregamos un menu una de las opciones del menu sera 1.- Catalogo de Articulos (CRUD a los diferentes articulos para la venta) como lo invoco a dicho catalogo? el uses lo hago en interface o en implementation si coloco el uses frmArticulo_f.pas (en el cual estan incluidos los demas form's) cual seria la utilidad de articulo.bpl ??? o es que estoy entendiendo mal? una unidad se puede autoreconocer que esta en una bpl?? (es algo disparatada esta pregunta) tengo otra duda sobre las variables publicas (yo las defino en el datamodule) se veran dentro de la bpl???
__________________
Dulce Regalo que Satanas manda para mi..... Última edición por oscarac fecha: 13-09-2019 a las 03:09:56. |
#11
|
||||
|
||||
Se me hace complicado con tantos datos y nada concreto hacerme una idea.
Si no te importa (y cogiendo un ejemplo de la primera referencia que has hecho) adjunto un proyecto sencillo sobre el que hacer las pruebas. Se trata de un grupo de proyectos formado por: (1) Un Package (restas) que contiene una unit con funciones (URestas) y un formulario (UMain). (2) Una aplicación con 2 botones. Uno llama a la función contenida en (URestas) y otra abre el form contenido en (UMain) Las formas de generar la aplicación serían: OPCION 1: Un único EXE (sin packages) Basta con que desde la aplicación principal estén accesibles todas las units y en la configuració marcar: "Link with runtime packages" a FALSE Y en el path de búsqueda he añadido el directorio donde están las units del package (Restas) para que las encuentre. ==> Esto genera un EXE de un poco más de 2MB. El compilador coge todas las units que necesita (que están en los USES) y las añade a la aplicación. Si revisamos en EXE con un editor de recursos, podemos ver tanto el formulario de la aplicación como el formulario UMain están incluidos. Es correcto, porque queremos una aplicación (EXE) que lo contenga todo. Si comprobamos la dependencias del EXE veremos que no necesita ninguna BPL, cosa que también es correcto. OPCION 2: EXE + BPL (carga estática) En este caso empezamos compilando el Package (Restas). He cambiado la configuración de este package para que el BPL y el DCP resultante vayan a parar al mismo sitio donde se genera el EXE (no es obligatorio, pero en este caso facilita las cosas). ==> Esto genera un fichero BPL de 38KB Si revisamos el contenido vemos que contiene el formulario (UMain), como es lógico. Ahora cambiamos la configuración de la aplicación (sólo necesitamos cambiar la configuración) para que compile con package. Activamoes el flag "Link with runtime packages" a TRUE y añadimos el packages Restas. Compilamos la aplicación. NOTA IMPORTANTE: Al decirle que use el Packages Restas, como el programa sabe qué contiene ese package, lo que va a hacer es que cuando encuentre en un USES la unit URestas y el formulario UMain, NO LOS VA A AÑADIR AL EXE, porque sabe que en ejecución los va a encontrar dentro del package (Restas). ==> Vemos ahora que el EXE resultante ocupa 36KB (era lógico que ocupara mucho menos; Ahora no contiene ni lo del package Restas ni lo de la VCL). Si revisamos el EXE vamos que ahora NO contiene el formulario UMain del package Restas (sólo tiene uno a diferencia de la generacion anterior). Si miramos las dependencias del EXE ahora aparecen los packages que necesita para funcionar (Restas.bpl, rtl250.bpl, vcl250.bpl). estos package se DEBEN DISTRIBUIR con la aplicación de forma obligatoria para que funcione. Si sigues los pasos, deberías poder generar la aplicación con los 2 escenarios. Tus dudas están en el segundo caso, pero como has visto, a la hora de programar no hay que hacer NADA DIFERENTE. El código no cambia y lo único que hacemos es poner las cosas (formularios y Units) en lugares diferentes. La aplicación principal en el trabajo del día a día debe tener acceso a todos los formularios y units (sean DCUs o PAS), pero cuando finalmente se compilan y se linkan los paquetes y la aplicación, Delphi conoce lo que hay en cada Package y NO LO AÑADE a la APP principal, sino que guarda una referencia de a qué BPL debe ir a buscarlo.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#12
|
|||
|
|||
Cita:
He estado haciendo pruebas y el tema que veo es que los Packages que se cargan de forma automática (estaticos) en el proyecto van a un bloque de memoria y los que se cargan de forma dinámica van a otro bloque de memoria distinta, entonces si un mismo package, en mi caso la unidad plugins.pas, se utiliza de ambas formas tanto en paquetes estáticos como dinámicos, en realidad hay dos instancia totalmente distintas de estos datos, y cuando intentan interactuar entre ellos no se ven. En las distintas pruebas que he estado haciendo dentro de los paquetes cargados de la misma manera, sean dinámicamente o estáticamente y siempre que no se mezclen esos paquetes, entonces parece que las variables "globales" si que se pueden compartirse sin problemas. El tema de utilizar estas variables globales es por ejemplo, el caso mas básico, un paquete con las conexiones de acceso a la base de datos, que lo va a utilizar el resto de paquetes:
Seguiré haciendo mas pruebas para verificar que no hace cosas extrañas Gracias a todos por la ayuda!! |
#13
|
||||
|
||||
Cita:
cuando distribuya el modulo tendre que entregar modulo.exe y articulos.bpl asi es? pregunta del millon, en el BPL tengo algunas otras unidades comunes, cuando las invoque en otras opciones, se llamaran dela BPL o de las units que estan fuera de la BPL
__________________
Dulce Regalo que Satanas manda para mi..... Última edición por oscarac fecha: 26-11-2019 a las 18:13:07. |
#14
|
||||
|
||||
Cita:
Correcto. No sólo las tuyas sino también las de la VCL que necesites. Si te dejas alguna, el programa dará un error al ejecutar. Cita:
Lo mismo de antes. El el USES tu colocas el nombre de la unit (PAS) que contiene la función que vas a ejecutar. Al generar el ejecutable (si está marcado "Build with runtime packages"), delphi no añade esa información al EXE, sino que en ejecución irá a buscarla a la BPL. Depende del USES que hayas usado.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#15
|
||||
|
||||
estoy haciendo esto
he creado una bpl donde estan las unidades necesarias creo un proyecto grupal llamado grupoPbl adiciono un proyecto llamado PruebaArt entonces quedaria PruebaArt Articulo.pbl en PruebaArt creo un formuladio MDIform un menu un datamodule con conexion a la base de datos (ya conectada) y dentro del menu una opcion para mostrar el formulario uses frmtacalogoarticulo en la opcion del menu tengo frmCatalogoArticulo := TfrmCatalogoArticulo.create(self) frmCatalogoArticulo .show compilo con la opcion link with runtimes packages y luego cuando ejecuto y activo la opcion para que se muestre el formulario con los articulos aparece este error, aunque despues me muestra el formulario vacio, sin datos Access violation at address 500613210 in module rtl210.bpl me orientas mejor?
__________________
Dulce Regalo que Satanas manda para mi..... Última edición por oscarac fecha: 26-11-2019 a las 21:09:18. |
#16
|
||||
|
||||
Crea el proyecto con todos los ficheros necesarios (o uno más sencillo de estructura similar) y súbelo como adjunto. Así lo podemos revisar. Escrito sólo como texto es complicado...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#17
|
||||
|
||||
listo
hice lo solicitado ahora no se pq no me genera el archivo PBL quiza lo esta creando en otro lugar yo uso una Unidad F espero q puedan darme una mano
__________________
Dulce Regalo que Satanas manda para mi..... |
#18
|
||||
|
||||
Aquí he modificado el proyecto cambiando un poco la estructura para que esté más claro y cambiando la fuente da datos por un fichero XML para no depender de la Base de Datos, pero eso no debería modificar lo que estamos hablando.
Tal y como está, el proyecto MODULO está "sin runtime packages". Por lo tanto si los compilas en el directorio de salida tendrás tres ficheros: Como está compilando "sin runtime packages", significa que el fichero MODULO.EXE lleva todo lo necesario para compilar. Si lo pruebas deberia funcionar y si borras el fichero ARTICULO.BPL, debería seguir funcionando, pues como hemos dicho MoDULO.EXE compila "sin runtime packages" y lleva todo lo necesario. Ahora prueba a cambiar para compilar MODULO "con runtime packages" Tienes los 3 ficheros en el directoriO de salida, pero si te fijas ahora los tamaños son distintos. En este punto MODULO.EXE NO contiene todo lo que necesita. Parte de ello está en el fichero ARTICULO.BPL El programa funciona de forma normal (igual que antes), pero con "runtime packages". Una prueba sencilla es BORrAR el fichero ARTICULO.BPL y verás que ahora MODULO.EXE no se ejecuta. Si miras las dependencias de MODULO.EXE verás que necesita al fichero ARTICULO.BPL
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#19
|
||||
|
||||
Cita:
cuando lo ejecuto sin check en runtimes packages el tamaño es mas grande, cuando compilo con esa opcion es mas chico pero me sale un mensaje de error access violation at adress 5005FEC in module rtl210.bpl quiero hacerle depuracion, pero antes de entrar a articulos aparece ese mensaje pregunta--- se puede hacer depuracion de/en un bpl?
__________________
Dulce Regalo que Satanas manda para mi..... |
#20
|
||||
|
||||
Cita:
¿Pero te sale ese error con el proyecto tal y como yo lo he subido? Si lo acabo de probar y funciona correctamente. Revisa y elimina todos los DCUs, BPLs y DCPs antes de comp0ilar el proyecto, no sea que te esté cogiendo otros ficheros que no son los que estás compilando. Cita:
También puedes hacerlo desde el proyecto de la BPL en el IDE, realizando un "attach" al EXE principal.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Creacion de Indices en ejecucion | javicho_villa | Impresión | 1 | 29-09-2005 06:27:21 |
Problemas con creacion de obj en ejecucion | mbcito | OOP | 4 | 21-01-2005 18:18:12 |
Creacion de formulario en ejecucion | Remp | OOP | 5 | 22-04-2004 19:14:15 |
Creación de tabla en tiempo de ejecución | sledgehammer | Conexión con bases de datos | 3 | 16-09-2003 15:08:01 |
Creacion de componente en tiempo de ejecución | cone220 | OOP | 1 | 16-09-2003 03:47:16 |
|