Plugins: Datenaustausch zwischen DLL und Hauptprogramm

[MyRealName]

Zitat von Elvis:

Zitat von MyRealName:

Ich weiss nicht, warum Du mir widersprichst, sagst doch nur etwas gegen BPLs und ich rede davon, wie man DLLs nutzen kann mit Klassen drin.

Weil ein unschuldiger Mitleser sonst den falschen Eindruck bekäme, dass Pseudo-Modularisierug mit Packages wirkliche Flexibilität bringen würde und einem nicht 70% der Haarpracht kostet.

Ich glaube, da muss man auch mal klar unterscheiden, wer denn Modularität in seinen Programmen benutzt oder benutzen will. Da sehe ich zum einen Gemeinschaftsprojekte im Internet, wo es wirklich schwer ist, alle auf dem gleichem Stand zu haben (zum Bsp. mit Delphi Version, Benutzten Komponenten etc). Und zum anderen Firmen, die ein oder mehrere Programme haben und sich Module bauen, um Funktionalität auszutauchen. Bei letzterem ist es weniger ein Problem mit den BPLs, da Firmen meist eh Delphi Lizenzen für alle Programmierer kaufen und alle auch mit Komponenten auf dem gleichem Stand sind. Ich selbst habe Jahre in einem grossen Projekt mit mehr als hundert Modulen gearbeitet, 3 Abteilungen waren daran beschäftigt, die ihre Sachen zum Modul-Pool hinzufügten und die andere Abteilungen nutzten. Das ganze natürlich mit Laufzeitpackages. Ich glaub, wir brauchten nur 4 Delphi bpls.

Zitat von Elvis:

Zitat:

Will man allerdings wirklich modular mit Delphi programmieren, muss man mit Laufzeit-Packages arbeiten (also zumindest die Komponenten-BPLs dynamisch linken).

Eben nicht. Wirklich modular ist man, wenn die Module nicht so grauenvoll miteinander verzahnt sind sind. Und das heißt, man ist "wirklich modular" wenn man DLLs benutzt und sich in den exportierten Funktionn auf interoperable Typen wie WideString, Integer, double, Interfaces, OleVariant, etc. beschränkt.
Denn dann explodieren Module nicht stets und ständig, weil irgendein Plugin eine neue Unit nutzt, oder wenn man eine neue Delphiversion nutzen will. Ganz zu schweigen davon, dass man dann Plugins mit anderen Sprachen schreiben kann z.B.: FPC, C++, C#,...

Das was Du willst, sind kleine Funktionsserver in DLLs, wo man mal dies oder jenes berechnet.
Ich sage ganz ehrlich, dass mit Kompatiblität zu anderen Compilern oder Programmiersprachen weniger interessiert. Das, mwas ich mit Delphi nicht machen kann, hat in Modulen eh nichts zu suchen. Und eine clever gebaute Bibliothek vrhindert auch grosse Probleme mit Laufzeitpackages.
So kann man zum Bsp. sein Internetkram (z.b. durch Indy Komponenten) in nur einem Module halten, braucht kein Laufzeitpackage dafür dann und sagt dem Module, was man braucht. Praktizier ich mit Erfolg in meiner Test-Anwendung.

Zitat von Elvis:

Zitat von MyRealName:

Allerdings sah ich auch durch mein Test-Programm, das sich neue Versionen von meinen Komponenten bauen konnte und meist auch ohne die Anwendung oder die DLLs zu kompilieren dann auch weiter nutzen. Man muss halt nur aufpassen, dass man keine published properties löscht Oder Methoden umbenennt.

Allerdings ist zu empfehlen, vorhandene Projekte neu zu übersetzen, wenn man ein neues Package baut

Dann könnte man gleich eine Single-Exe nehmen ohne all die Zeit mit Package-Issues zu verschwenden.

Nein, weil man ja die Packages nicht alle 2 Tage neu übersetzt. Es gibt ja schliesslich einen Stand, da sind die eigenen Komponenten fertig, ab da übersetzt man nicht mehr. Davor ist man insgesamt noch im Entwicklungs-Stadium und da macht es nichts aus, ob man neu übersetzt.