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.

[Sherlock]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1423298)

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.

Ah, DCU, danke.
Ich ging hier von einer InHouse-Situation aus. Ich würde auch keine Delphi Komponente in einer DLL kaufen ;-)

Sherlock

[Bernhard Geyer]

Zitat:

Zitat von Sherlock (Beitrag 1423300)

Ah, DCU, danke.
Ich ging hier von einer InHouse-Situation aus. Ich würde auch keine Delphi Komponente in einer DLL kaufen ;-)

Inhouse wäre Ablage der Sourcen in git wohl die Lösung und Build+Installscripts

[EWeiss]

Ich mache das über Interface..
erstelle eine globale Interface API und gut ist.

So das jeder auf deine DLL ohne umschweife zugreifen kann.
Aber als Komponente auf die Form klatschen ist nichts! :)
Wenn überhaupt geht es nur dynamisch.

Zitat:

Ich würde auch keine Delphi Komponente in einer DLL kaufen

Nun ja *.bpl sind auch nichts anderes als *.dll nur umbenannt.

gruss

[DualCoreCpu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1423298)

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.

Ich lese diesen Thread gerade und da fällt mit das .dcu Problem auf.

Das geht dann auch nur dann, wenn das dcu Format von Version zu Version gleich bleibt. In frheren Delphi Versionen war das nicht der Fall, da hat der Compiler gemeckert, wenn ich ein .dcu Datei einer falschen Delphi Version verwenden wollte. Sollte das jetzt anders sein. Kann ich heute in meinem Delphi 10.3 auch eine Unit im dcu Format aus Delphi XE7 verwenden? Wenn ja, seit welcher Delphi Version bleibt das dcu Format gleich?

[MyRealName]

Zitat:

Zitat von DualCoreCpu (Beitrag 1423309)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1423298)

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.

Ich lese diesen Thread gerade und da fällt mit das .dcu Problem auf.

Das geht dann auch nur dann, wenn das dcu Format von Version zu Version gleich bleibt. In frheren Delphi Versionen war das nicht der Fall, da hat der Compiler gemeckert, wenn ich ein .dcu Datei einer falschen Delphi Version verwenden wollte. Sollte das jetzt anders sein. Kann ich heute in meinem Delphi 10.3 auch eine Unit im dcu Format aus Delphi XE7 verwenden? Wenn ja, seit welcher Delphi Version bleibt das dcu Format gleich?

Die dcu's sind nicht kompatibel zwischen den Delphi Versionen, da sie ja mit anderen version der RTL und VCL etc. compiliert wurden.
Was du machen kannst ist halt für jede Delphi version selbst zu kompilieren und dann jeweils dcu/dcp/bpl für jede Delphi Version ausliefern, aber die Leute müssen dann ihr Projekt neu erstellen mit der neuen Version der Komponente, falls du properties eingefügt hast etc.

[peterbelow]

Die einzige Alternative, die mir da einfällt, wäre, das Control in ein COM-Control zu verpacken. Dann hast Du eine DLL, die dann aber leider auch auf jedem Rechner zusammen mit dem fertigen Programm installiert und registriert werden muss. Das COM-Control importierst Du dann einmal in Delphi, um daraus eine VCL wrapper control zu machen, die dann in dem Programm verwendet wird. Diese Unit sollte sich dann nie mehr ändern müssen, es sei denn, Du mußt später was an dem publizierten Interface des COM-Controls ändern.

Meines Erachtens ist das alles viel zu aufwendig und fehleranfällig. Du solltest lieber selbst eine XE7-Installation haben, auf der Du all Änderungen direkt testen kannst, damit deine Kollegen nicht später in Probleme laufen. Versionsspezifische Konstrukte im Code für XE7 und Berlin kannst Du dann mit conditional compilation Anweisungen kapseln, so dass der Code auf beiden Platformen problemlos kompilierbar ist.

[mschaefer]

Moin

Visuelle Komponenten in dll fuehrt zu vielen Ueberraschungsproblemen. Was einigermasen sinning geht, ist das Auslagern von Dialogen in dll's. In diesen kann man dann auch eigene Komponenten einsetzen.

[TurboMagic]

Es war hier von andere Programmierer der Firma die Rede, da würden DCUs denke ich gehen, nur technisch scheidet das dann doch aus,
weil DCUs Delphi versionsspezifisch sind :(

Evtl. ist's wirklich sinnvoll hier mal zu diskutieren welche Probleme es gibt, wenn man innerhalb der Firma den Quellcode der
Komponenten weiter gibt. Evtl. gibt es Lösungen zur Beseitigung dieser Probleme.

[Bernhard Geyer]

Einmal zurück auf Anfang:

Zitat:

Zitat von skoschke (Beitrag 1423246)

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.

Achte darauf das du keine Properties beim Entwickeln mit 10.1 hast.
Sorge dafür das du auch ein XE6/7 hast mit dem du deine Komponente als Packages (mit Quellcode) bereit stellst.
Und das "Neukompilieren" robleme bereitet wäre mir neu.

Zitat:

Zitat von skoschke (Beitrag 1423246)

Weiterhin könnte man später beim Anwender des Programms bei Erweiterungen nicht die gesamte Anwendung, sondern nur die DLL austauschen...

Kannst du nicht wenn du nicht alle Vorteile der VCL aufgeben willst

Ich hatte früher auch mal eine Projekt (VS C++) welche auf diesen Konzept aufgesetzt hat.
Die Programmiereffektivität wurde besser als diese DLL-Logik aufgegeben wurde.
Statt auf 3 Disketten passte das programm dann wieder auf eine Diskette ...

Zitat:

Zitat von skoschke (Beitrag 1423246)

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

Machbar Ja (mit viel Aufwand). In deinem Fall aber m.E. überhaupt nicht sinnvoll.


Wieso versucht ihr nicht alle immer die gleiche IDE-Version zu haben?
Vereinfacht manches. und ein Update von XE6/7 auf 10(.x) ist auch nicht mehr so schwer (gegenüber einem Update z.B. von D6 auf eine 10.xer Version.

[jaenicke]

Wie sieht es denn mit einer Buildmaschine aus? Ich gehe doch mal angesichts mehrerer beteiligter Entwickler davon aus, dass eine solche verwendet wird, oder?
Die kompiliert die Quelltexte doch sowieso. Da würde es ja reichen, wenn die kompilierte Variante dann per Skript auf den Entwicklerrechnern landet.

Davon abgesehen sehe ich es aber auch so, dass es keinen Sinn macht, wenn nicht auch XE6/7 zur Entwicklung mit installiert sind, denn wie soll sonst "naturnah" getestet werden? Und dann könnte man die kompilierten Dateien auch dort ziehen.

Eine eigene Buildmaschine stellt aber zusätzlich ja noch sicher, dass nicht lokale Änderungen in den Build einfließen, insofern halte ich beides für wichtig.

[skoschke]

Zitat:

Wieso versucht ihr nicht alle immer die gleiche IDE-Version zu haben?

Das ist bei einer kleinen Firma wie bei uns, eine Preisfrage, die "alteingesessenen Entwickler" haben XE7, ich Neuling habe Berlin 10.1

Alle nun auf 10.1 zu stellen macht auch bei vielen eingesetzten Kaufkomponenten, die es nur für <=XE7 gibt, weitere massive Umstellungs-Probleme...

Dass ich 10.1 bekam, lag eigentlich daran, dass ich hauptsächlich Android-Apps baue, als "Einzeltäter", nur jetzt soll ich eben Programmteile für das XE7-Hauptprogramm schreiben.

Es wäre halt schön, wenn man meine 10.1-Komponente(n) ohne viel Aufwand in dem XE7-Projekt verwenden könnte...

Ciao
Stefan

[jaenicke]

Zitat:

Zitat von skoschke (Beitrag 1423399)

Das ist bei einer kleinen Firma wie bei uns, eine Preisfrage, die "alteingesessenen Entwickler" haben XE7, ich Neuling habe Berlin 10.1

Deshalb stehen ja bei einem Neukauf alle verfügbaren alten Versionen ebenfalls zur Verfügung, auch die genannten...
Damit man eben die alte und die neue Version parallel installieren kann, wenn mehrere verwendet werden.

Das Problem ist, dass die Anforderung dieser Versionen innerhalb eines halben Jahres nach Kauf passieren muss:
https://www.embarcadero.com/de/produ...vious-versions

Aber vielleicht kann der Support dabei trotzdem helfen...