Delphi-PRAXiS
Seite 2 von 3     12 3   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Eigenentwickeltes Control in DLL verpacken? (https://www.delphipraxis.net/199306-eigenentwickeltes-control-dll-verpacken.html)

Sherlock 14. Jan 2019 14:42

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 14. Jan 2019 14:59

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 14. Jan 2019 15:11

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 14. Jan 2019 20:38

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 14. Jan 2019 22:42

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 15. Jan 2019 10:52

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 15. Jan 2019 12:32

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 15. Jan 2019 21:24

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 15. Jan 2019 21:48

AW: Eigenentwickeltes Control in DLL verpacken?
 
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 16. Jan 2019 05:20

AW: Eigenentwickeltes Control in DLL verpacken?
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 20:45 Uhr.
Seite 2 von 3     12 3   

Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf