Cita:
Empezado por BlackDaemon
Ya he visto tu sistema de plugins y no es lo que necesito hacer, por cierto igual ahí usas lo mismo que yo estoy aprendiendo, a cargar bpls dinámicamente
|
Pues justamente por eso te recomendé que leyeras el artículo y que revisaras el proyecto de ejemplo (que por cierto he corregido el link porque no era correcto). Porque ahí se hace lo mismo que tú estás haciendo (GetClass) y sí funciona correctamente.
Cita:
Empezado por BlackDaemon
ahora, con lo de la apuesta creo que te gano  |
Todavía albergo esperanza...
Cita:
Empezado por BlackDaemon
ya que según he leido (espero haber entendido bien) osea si marcas esa casilla y compilas de esa forma qué pasaría si NO existiría el package1.bpl ? lanzaría un error, es mas, en el ejemplo 1 de ese mismo fantástico artículo explican de hacer check a esa casilla, que por cierto ya no es
vcl50;Package1.bpl. yo uso delphi 2009 y con eso no me funcionó, cambié a solo vcl;Package1.bpl y así si funcionó perfectamente, pero está claro el mismo artículo dice que qué pasaría si no distrubuyo el bpl. la app fallaría, entonces por este mismo motivo es lo que hacen el ejemplo2, osea cargarlos dinámicamete y ya SIN linkear, y es ahí ya donde no me funciona el ejemplo2 de ese zip del artículo.
|
Pues creo que eso es lo que no has entendido bien.
PREMISA PARA PODER UTILIZAR RTTI (GetClass): Tanto en el artículo de Vino Rodigues (parte del FINALLY) como en el mío (donde están las RECOMENDACIONES), se deja bien claro que el Check "
Build with runtime Packages" debe estar marcado. ¿Porqué? Por explicarlo de una forma sencilla, si compilas
sin Runtime packages la información de RTTI del programa principal y de los packages dinámicos no se encuentra en el mismo lugar, por tanto al acceder desde el programa a esa información del package (con GetClass), no la encuentra. La única forma de que esa información esté accesible es compilando el programa con Runtime Packages.
Por otro lado están los packages que se cargan de forma estática, que son los que aparecen en la lista que comentas. El package1 que aparece en esa lista, se carga de forma estática, por eso está ahí. Los packages que tú vas a cargar de forma dinámica (con
LoadPackage)
no deben estar es esa lista. Por la razón que tú comentas (si no existieran fallaría la aplicación).
(1) Activa el CheckBox en las opciones del proyecto.
(2) Elimina los packages que vayas a cargar con LoadPackage de esa lista
(3) Ejecuta el código y prueba el GetClass.
CONCLUSIONES.
(1) Si tu aplicación se compila/linka
sin packages dinámicos (todo en un EXE),
puedes usar LoadPackages para cargar packages dinámicos, pero
no podrás utilizar la información de RTTI (por ejemplo GetClass) de los packages cargados con LoadPackages desde la aplicación (GetClass de las clases del package siempre devolverá nil).
(2) Si tu aplicación compila
con runtime packages, hay packages
cargados estáticamente (de los que has hecho un USES -los de la VCL, por ejemplo-) y que estarán en la lista de packages (si no están la aplicación falla) y packages
cargados dinámicamente con LoadPackage. Estos últimos no deben estar en la lista de packages (opciones del proyecto) y si no están disponibles,
fallará la llamada a LoadPackage, pero no la ejecución de la aplicación. Con este escenario
la información RTTI de todos los packages cargados (estáticos y dinámicos) está en el mismo lugar, por lo tanto puedes acceder a ella -para todos los packages- sin problemas (Getclass).
Espero haberme expllicado medianamente bien.
Un saludo.
P.D: Sigo creyendo que ganaré la cerveza.
