DLL mit Runtime-Packages: Entladehemmung!?

[negaH]

Wenn du ladbare DLLs mit Packages kombinierst dann müssen gewissen Regeln eingehalten werden:

1.) alle DLLs müssen Packages benutzen, und zwar alle Packages die benötigt werden
2.) niemals ShareMem oder FastMM oä. benutzen das ist absolut unnötig und fehleranfällig. Da alle Objekte über die RTL und damit über das System-Package alloziert werden hat man in diesem Moment sowieso einen gemeinsam benutzten Memory Manager, auch ohne ShareMem !
3.) alle gemeinensam zu benutzenden Klassen gehören in Packages
4.) alle "unsichtbaren" Klassen wie die speziellen Formulare, Reporte usw. können in den DLLs verbleiben. Der Aufruf von is und as auf solche "privaten" DLL-Klassen muß dann ein Vergleich mit der in Packages implementierten Vorfahrklassen sein. Also zb. Self is TForm oder Self is TCustomForm, aber nicht Form12 is TDLL_Form15 wobei Form12 zb. in DLL_12 und die Klasse TDLL_Form15 in DLL15 implementiert wurde.

Somit gilt: die Packages stellen eine gemeinsam benutzten Brückenkopf zwischen den nachladbaren und privaten Endstellen in Form einer DLL dar.

Dann musst du sehr genau überprüfen welche 3'rd Party Packages du einbindest. Sehr oft haben deren Entwiker nicht berücksichtigt das deren Packages eben auch zur Laufzeit geladen und entladen werden können. Zb. Report Builder oder QuickReport. Beispiel: Hauptanwendung ist 34kB große EXE und lädt ein allgemeines TMainForm aus einem Package "Main" für die Anwendung. Diese EXE importiert aber eben nicht statisch schon die Report Packages. Erst wenn über das TMainForm eine DLL geladen wird, zb. ein Report in einer DLL, werden in diesem Moment auch alle zusätzlichen Packages für diese DLL nachgeladen. Wird nun der Report freigegeben und daraufhin diese DLL wieder entladen so werden auch diese Packages autom. wieder entladen. Nun benutzen aber einige der Komponenten in solchen Packages globale Hooks, zb. Application.OnMessage() als Events. Diese werden meistens in der Initialization/Finalization Sektion einer Unit installiert und wieder deinstalliert (wenn überhaupt deinstalliert wird). Sowas bringt massive Probleme mit sich. Einfach weil die Entwickler dieser Komponenten nicht daran gedacht haben das ihre Packages nicht statisch sondern dynamisch geladen und eben auch wieder entladen werden. Abhilfe ist es dann in der Main.EXE der Anwendung diese Packages sofort und einmalig nachzuladen, oder aber die Formular/Report-DLLs einmal geladen nicht wieder zu entladen.

Die Sache ist also: entweder mit Packages arbeiten und dann aber richtig und absolut konsequent oder erst garnicht damit anfangen. Alle nachladbaren Module in DLLs packen, aber mit dem Hintergedanken das deren darin implementierten Klassen absolut privat sind. Das ist sogar von Vorteil da man so mit sauberen Schnittstellen Modulübergreifend arbeiten muß und einer striktere Modularisierung entsteht.

Gruß Hagen