Beispiel
dll/
bpl A enthält Fastreport
dll/
bpl B enthält Fastreport
Fastreport registriert sich über Registerclass
Modul A kann problemlos verwendet werden.
Modul B kann problemlos verwendet werden.
Wird versucht eines der beiden Module nachzuladen, wenn das jeweils andere Modul bereits geladen ist, dann knallt es und die Anwendung stürzt ab.
Hier nützen mir auch Interfaces nicht.
Das Problem kann ich einzig über ein
Com-Object lösen.
Ich selbst habe mir ein Pugin-System auf Basis von Exe-Dateien gebaut.
Das Hauptprogramm ruft über einen Taskcontroler eine EXE auf und versorgt diese über Aufrufparameter.
Die Exe selbst kann z.B. ein beliebiges Panel im Hauptprogramm als Parent haben.
Das Ganze kann sowohl wie Show oder Showmodal aufgerufen werden. Nach Beenden des der Plugin-Exe kann ein Returncode ausgewertet werden.
Beispiel:
Nach Klick auf einen Menüpunkt ein externes Programm modal starten, im Parent des aufrufenden Programmes anzeigen. Auf Beendigung warten und dann den Return-Code auswerten.
Delphi-Quellcode:
Tools : TTaskControl;
Tools := Task.Init(Parent, nil,'AUTTOOLS.EXE',modal);
res := AutPlugin.Task.Startmodal(Self,Tools,'Kunde=1234,Rechnung=456,Artikel=1/2/3');
Warum ich keine
bpl/
dll verwende:
Die Module müssen immer in der gleichen Umgebung wie die exe kompiliert sein.
In unsauberen Umgebungen wie sie ab D7 abwärts entstanden sind, (z.B.
bpl in System32) gilt das für alle anderen Delphiprogramme auf dem Rechner auch.
Also ich liefere Programm A,B,...Z an den Kunden aus. Dazu die Laufzeitumgebung. Alles läuft wunderbar.
Jetzt nehme ich für Programm J eine Änderung an irgendeinem Laufzeitmodul vor. Fazit neben den Änderungen für Programm J muss ich A..Z neu kompilieren und mit
ausliefern.
Von einem kleinen Compilerwechselchen von z.B. D2009 auf D2010 habe ich da noch garnicht geredet.
Delphi und Net haben den gleichen geistigen Vater. Net ist aus den Erfahrungen mit der Delpi- Entwicklung entstanden und Assemblys entschärfen fast alle Probleme , die bei der Modularisierung mit veralterten Programmiersystemen entstanden sind.
Wer heute noch größere Programmsysteme und diese auch noch modular ohne Sachzwänge mit D32 anfängt ist selber dran schuld.
Unter Sachzwängen verstehe ich entweder riese Altlasten an Code oder ein fortgeschrittenes Alter, wo ein Umgewöhnen nicht mehr möglich oder sinnvoll ist.
Dazu kommt im Vergleich zu anderen
IDE noch die seit Versionen bugige
IDE von Delphi.
Dabei muss man sich nichtmal von EB/CG und Delphi verabschieden, mit Delphi Prism steht eine um Generationen bessere Delphi-Version zur Verfügung.
Wenn ich nach Italien in den Urlaub fahre und habe einen Mercedes und einen Trabi-Oldtimer in der Garage stehen, dann nehme ich auch den Mercedes und nicht den Oldtimer.
Obwohl unter Abenteuergesichtspunkten ? ...
Gruß
Peter