Die hier zitierten Argumente relativieren das
Package Problem nun auch wieder, aber für mich ist und bleibt dieses Problem auch ein interessanter Aspekt. Ich habe nämlich noch immer nicht verstanden, warum hier die totale Neuübersetzung überhaupt erforderlich ist. Mir ist klar, das dies der Fall ist, wenn die Komponenten als neue Units statisch eingebunden werden. ABER: Kann man diese nicht auch als normale Dlls einbinden, per Interfaces?
Lazarus und Delphi instanziieren die Komponenten und rufen deren Methoden auf (das
csDesigning
in
TComponentState
gibt es nicht zum Spaß). Zum Finden der Ereignisse und zum laden/speichern der LFM/
DFM wird die
RTTI benötigt und die Klasse muss dem Komponenten Streaming System bekannt sein.
Aus diesem Grund musst du übrigens die Lazarus
IDE nur neukompilieren, wenn du entweder ein
Package installierst, welches die
IDE erweitert, oder, wenn du Komponenten im Formdesigner verwenden möchtest. Legst du die Komponenten nur zur Laufzeit an, dann reicht es, wenn Lazarus das
Package kennt (soll heißen: du hast einmal die
LPK-Datei geöffnet) und du die entsprechende Abhängigkeit im Projektinspektor einstellst.
Ein Komponentenmanager könnte so aussehen (nur Interface)
type
IComponentFactory = Interface(IInterface)
function GetComponents(Index: Integer): TComponent;
procedure SetComponents(Index: Integer; value: TComponent);
property Components[Index]: TComponentList read GetComponents write SetComponents;
property ComponentCount: Integer; //Anzahl aktuell in
IDE verfügbare Komponenten
end;
Nun müssten die Komponenten von außen per
dll angeschlossen werden;
Wo ist da mein Denkfehler, wenn da einer ist?
Ein ganz, ganz wichtiger Denkfehler: Ohne Dynamic Packages gilt, dass
TComponent
der
IDE nicht das selbe
TComponent
der Bibliothek ist. Das heißt, für eine Komponente, die in der
IDE instantiiert wird, aber in einer
DLL implementiert ist, wird
is TComponent
innerhalb der
IDE nie
true
zurück geben. Auch Exceptions in den Komponenten können dadurch nicht abgefangen werden, da selbst ein
on e: TObject do {...}
fehlschlagen würde, da auch
TObject
in der
IDE und
TObject
in der
DLL unterschliedliche Typen sind. Das ist einer der Hauptgründe, weswegen Dynamic Packages entwickelt wurden: dabei wird die
RTL in eine eigene Bibliothek (
Package) ausgelagert und sowohl
IDE, als auch die Komponenten Bibliothek (
Package) können diese verwenden und der Compiler kümmert sich darum, dass bezüglich Abhängigkeiten alles passt und somit auch nur eine einzige Art von
TObject
,
Exception
oder
TComponent
existiert.
Ganz davon abgesehen würde dies dazu führen, dass die Komponente extra für Lazarus angepasst werden müsste (ich sehe jetzt hier mal von anderen Problemen mit der Kompatibilität ab), was hieße, dass es noch weniger Komponenten für Lazarus gäbe, als es eh schon der Fall ist.
Gruß,
Sven