creacion y ejecucion de bpl

[[oscarac]]

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

[[movorack]]

Hola, de pronto este pequeño ejemplo te sirva de algo.

https://bitbucket.org/mivaler/delphi...rm-into-a-bpl/

[[oscarac]]

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)

[[movorack]]

En el ejemplo que te dí, la BPL como tal no la invocas.

Es decir, no la inicializas como a una dll

Código Delphi [-]
  Handle := LoadLibrary('libraryname');
  if Handle <> 0 then
  begin
    @GetTime := GetProcAddress(Handle, 'GetTime');
    if @GetTime <> nil then
    begin
      GetTime(Time);
      with Time do
        Writeln('The time is ', Hour, ':', Minute, ':', Second);
    end;
    FreeLibrary(Handle);
  end;

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.

Código Delphi [-]
Unit UForm1;

..

implementation

uses
  UForminBPL;

..

TForm1.ButtonClick1(Sender: TObject);
begin
  with TFormInBPL.Create(Application) do
  try
    if ShowModal then
    begin
      //
    end;
  finally
    free;
  end;
end;

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

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

Empezado por oscarac

la pregunta del millon es...
como hago para utilizarlo?

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).

Empezado por oscarac

he estado revisando ejemplos
https://neftali.clubdelphi.com/dlls-...es-en-runtime/

pero como que no los he entendido muy bien

Si necesitas aclaración de algo en concreto dilo e intentaremos aclararlo.
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

Empezado por oscarac

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.

Es correcto.
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,...

Empezado por oscarac

esos formularios "de uso comun" como los puedo utilizar?

Depende de la primera pregunta. Si quieres (1) o (2)

Empezado por oscarac

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?

No entiendo que quieres decir con incluir una "BPL dentro de otra". Como has dicho son DLL's. Son ficheros diferentes.
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.

[[oscarac]]

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

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).




Si necesitas aclaración de algo en concreto dilo e intentaremos aclararlo.
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



Es correcto.
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)



No entiendo que quieres decir con incluir una "BPL dentro de otra". Como has dicho son DLL's. Son ficheros diferentes.
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.

gracias por responder

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

[bucanero]

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:

Empezado por oscarac

buenos dias
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?

Y esto afecta, digamos por ejemplo a que esa variable es por ejemplo un plugin con los tipos de IVA que va a usar nuestra aplicación, y a su vez lo van a usar otros plugins (ventas, clientes, articulos)

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

Empezado por bucanero

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:

Y esto afecta, digamos por ejemplo a que esa variable es por ejemplo un plugin con los tipos de IVA que va a usar nuestra aplicación, y a su vez lo van a usar otros plugins (ventas, clientes, articulos)

Lo primero decir que si estás utilizando plugins (con carga dinámica de packages) utilizar variables globales en el plugin (si luego debes accederlas desde fuera) me parece un error de concepto.

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.

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

Empezado por oscarac

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)

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.

Empezado por oscarac

la pregunta es.. como invocarlo?
suficiente con colocar uses en la unidad?
osea un uses articulo.bpl ???
espero haberme explicado bien

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.

[[oscarac]]

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...

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

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.

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???

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

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.

[bucanero]

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

Lo primero decir que si estás utilizando plugins (con carga dinámica de packages) utilizar variables globales en el plugin (si luego debes accederlas desde fuera) me parece un error de concepto.

¡¡¡Gracias Neftali por responder!!!

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:

Código Delphi [-]
PackageConnection [---
   Unit DMConnections;
   interface
   type
     TDMConnection = class(TDataModule)
...
     end;

  var
    DMConnection :TDMConnection; /// Instancia a la conexión de la BBDD
  ...
   end.
---]

PackageClientes [---
   Unit DMClientes;
   interface
   type
     TDMClientes = class(TDataModule)
  ...
     end;

   implementation       

   uses DMConnections; /// acceso a la instancia a la conexión a la BBDD
   ...
   end.
---]

Seguiré haciendo mas pruebas para verificar que no hace cosas extrañas
Gracias a todos por la ayuda!!

[[oscarac]]

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).

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.

entiendo con esto que lo que hace el BPL es "aislar / separar / encapsular" código (unidades formularios, etc) que no estarán incluidos en el exe, delphi "automaticamente" identifica que el form artículos esta dentro del bpl articulos y lo ejecuta de ahi

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

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

Empezado por oscarac

...entiendo con esto que lo que hace el BPL es "aislar / separar / encapsular" código (unidades formularios, etc) que no estarán incluidos en el exe, delphi "automaticamente" identifica que el form artículos esta dentro del bpl articulos y lo ejecuta de ahi
cuando distribuya el modulo tendre que entregar modulo.exe y articulos.bpl
asi es?

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.

Empezado por oscarac

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

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.

Empezado por oscarac

se llamaran dela BPL o de las units que estan fuera de la BPL

Depende del USES que hayas usado.

[[oscarac]]

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?

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

Empezado por oscarac

me orientas mejor?

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...

[[oscarac]]

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

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

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

[[oscarac]]

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

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

efectivamente he hecho la prueba y los tamaños cambian

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?

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

Empezado por oscarac

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

¿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.

Empezado por oscarac

quiero hacerle depuracion, pero antes de entrar a articulos aparece ese mensaje
pregunta--- se puede hacer depuracion de/en un bpl?

Si. Exactamente igual que con el programa principal.
También puedes hacerlo desde el proyecto de la BPL en el IDE, realizando un "attach" al EXE principal.