Eigenentwickeltes Control in DLL verpacken?

[Sherlock]

Zitat von Bernhard Geyer:

Zitat von Sherlock:

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 von Sherlock:

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 von Bernhard Geyer:

Zitat von Sherlock:

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 von DualCoreCpu:

Zitat von Bernhard Geyer:

Zitat von Sherlock:

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 von skoschke:

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 von skoschke:

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 von skoschke:

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.