Eigenentwickeltes Control in DLL verpacken?

[skoschke]

Hallo,

ich spiele mit dem Gedanken, ein eigenes Control in eine DLL zu verpacken und es zur Laufzeit aus der DLL zu laden und auf ein Form zu platzieren.

Hintergrund:
Es wird mit D10.1 entwickelt, andere Verwender haben XE6/7 und ein ständiges Neukompilieren bei Erweiterungen macht Probleme.
Weiterhin könnte man später beim Anwender des Programms bei Erweiterungen nicht die gesamte Anwendung, sondern nur die DLL austauschen...

Ist das überhaupt machbar (und wenn ja wie) oder eine Schnapsidee?

Ciao
Stefan

[CCRDude]

Da gibt es viele Seiten:

1. Mit einer DLL bindest Du den Code, der sonst auf zig Platformen laufen könnte, erstmal auf eine fest (bzw musst binaries für viele Platformen erstellen) - wenn Du mehrere Platformen überhaupt unterstützen möchtest.
2. Unter Windows gibt es dafür ActiveX. ActiveX-Controls lassen sich auch in Delphi erstellen. Aber dann halt ganz gebunden an diese Platform (ob das auch mit FMX oder nur mit VCL klappt, weiß ich nicht).
3. Die DLL würde erstmal eine eigene Version der VCL einkompiliert haben, da gibt es etliche Fallstricke (etwa kein gültiges Application-Objekt).
4. Lokalisierungs-Code würde solche Controls nicht automatisch behandeln können.

Bevor ich so einen Aufwand überlegen würde, würde ich mir vermutlich erst einmal lange Gedanken machen, ob ich mein Konzept nicht so verbessern könnte, dass ständiges Neukompilieren eben keine Probleme macht. Denn ob es nun Änderungen an der Pascal-Schnittstelle oder an der DLL-Schnittstelle sind - in beiden Fällen ist eine stabile saubere Schnittstelle das A und O.

[jaenicke]

Vor allem ist ein Kompilieren bei den Verwendern ja gar nicht nötig. Es würde ja auch reichen Binaries auszutauschen, wenn dort nichts am Quelltext geändert werden soll.

Wir machen das alles per Batchdatei. Ein Doppelklick und alle Einstellungen und Pfade sind gesetzt, dann noch per Batch die Packages kompilieren, fertig.

[TiGü]

Ich möchte noch einen Schritt zurückgehen und fragen, ob es sich wirklich um eine visuelle Komponente handelt.

[peterbelow]

Es ist nicht unmöglich, aber es gibt viele Fallstricke, besonders, wenn es sich um eine visuelle Komponente handelt. Viel hängt auch davon ab, wie das Hostprogramm die Komponente verwendet. Falls das Hostprogramm die Klasse der Komponente kennen muss, um mit ihr zu arbeiten (d.h. Du kannst sie nicht als Instanz der VCL-Basisklasse behandeln, von der sie abgeleitet wurde) hast Du ja zwei unterschiedlich kompilierte Versionen des Sourcecodes, die im Host-Programm eingebundene und die aus der DLL. Ein Aufruf einer statischen Methode im Hostprogramm würde den Code im Hostprogramm aufrufen, eine virtuelle Method dagegen den in der DLL. Und bei größeren Sprüngen in den verwendeten Delphi-Versionen kann das in-memory layout der von der DLL erzeugten Instanz sogar von dem abweichen, was das Hostprogramm erwartet.

Das Ganze ist ein Minenfeld, in das ich mich nicht vorwagen würde :wink:.

Was so halbwegs funktioniert ist folgendes: Du definierst einen Interface-Type für die Interaktion mit der Komponente in einer separaten Unit, die sowohl von Hostprogramm als auch von der DLL verwendet wird. Die DLL exportiert eine Funktion, die eine Instanz der Komponente anlegt und das Interface dafür zurückgibt. Falls es eine visuelle Komponente ist übergibst Du der Funktion das Windows-Handle des Host-Controls und verwendest den CreateParented-Constructor um das Control (muss ein TWinControl sein!) zu erzeugen. Alle Interaktion des Hosts mit dem Control erfolgt über das Interface, oder durch Senden von Messages. Dadurch ist sichergestellt, dass es keine Konflikte durch unterschiedlichen Code in VCL oder RTL gibt. Trotzdem sollte man bei den Parametern in den Methoden des Interfaces auf compiler-managed types wie String oder array of <type> verzichten, den sonst brauchen beide Module auch noch einen gemeinsamen Memory manager, was auch nicht problemfrei machbar ist, wenn beide mit unterschiedlichen Delphi-Versionen kompiliert wurden.

[MyRealName]

Falls es etwas visuelles ist, welches dann dynamisch auf ein Formular soll, dann hast Du noch das Problem, dass DLL und exe unterschiedliche instanzen der VCL haben, da kommen dann Fehler wie "Kann TFont nicht TFont zuweisen". Um visuelle Sachen aus einer DLL zu nutzen, kompiliert man meist exe und DLL mit runtime packages

[skoschke]

Ohje...

Minenfeld, ich mag nicht ;-)

Das Problem ist eigentlich, dass ich eine Komponente mit Berlin 10.1 entwickle, welche von anderen Programmieren der Firma (die XE7 haben) dann im fertigen Programm weiterverwendet wird und bei denen dann ja der Komponentencode wieder erneut kompiliert wird...

Weil es da immer mal wieder zu Problemen kommt und wir nicht bei jeder kleinen Änderung die gesamte Anwendung austauschen können, dachte ich an die DLL-Variante...

Es geht ausschließlich um Win32 Anwendungen.

Wie könnte man alternativ vorgehen?

Ciao
Stefan

[Sherlock]

Zitat:

Zitat von skoschke (Beitrag 1423295)

Wie könnte man alternativ vorgehen?

Die Komponente in XE7 und Berlin entwickeln, und nicht als Quellcode weitergeben sondern als (wie heissen binary Komponenten?), vielleicht?

Sherlock

[Lemmy]

Zitat:

Zitat von skoschke (Beitrag 1423295)

Weil es da immer mal wieder zu Problemen kommt

welche Probleme denn?

die einfachsten Varianten:
Komponente auch in XE7 implementieren oder die Anwendung auf 10.1 umstellen oder in 10.1 nur solche Sprachfeatures verwenden, die auch in XE7 kompilieren.

[Bernhard Geyer]

Zitat:

Zitat von Sherlock (Beitrag 1423296)

wie heissen binary Komponenten?)

Es wird statt pas-Dateien die dcu-Dateien geliefert.
Aber es wird viele User geben die das nicht mitmachen werden und nur-dcu-Komponenten nicht kaufen/installieren werden.
Bei uns ist sowas auch ein Ausschlußkriterium.