Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Übergabe einer Klasse von EXE an DLL (https://www.delphipraxis.net/193865-uebergabe-einer-klasse-von-exe-dll.html)

mkinzler 18. Sep 2017 17:37

AW: Übergabe einer Klasse von EXE an DLL
 
Deshalb besser Interfaces benutzen.

norwegen60 18. Sep 2017 20:23

AW: Übergabe einer Klasse von EXE an DLL
 
Mmh, wie schon weiter oben gesagt, habe ich mich mit Interfaces noch nicht beschäftigt.
Ich habs mir heute mal angeschaut, verstehe aber nicht ganz wieso es mir im Fall Delphi zu Delphi helfen soll.

Wie würden mein Projekt sich denn Ändern, wenn es per Interfaces laufen würde?

Zacherl 18. Sep 2017 21:36

AW: Übergabe einer Klasse von EXE an DLL
 
Zitat:

Zitat von norwegen60 (Beitrag 1381526)
Wie würden mein Projekt sich denn Ändern, wenn es per Interfaces laufen würde?

Im Grunde nicht viel. Du müsstest dir für jedes Object alle Methoden, die über die Programmgrenzen hinweg aufgerufen werden in einem Interface deklarieren. Danach leitest du dein bestehendes Objekt nicht mehr von
Delphi-Quellcode:
TObject
, sondern von
Delphi-Quellcode:
TInterfacedObject
und
Delphi-Quellcode:
IMyInterface
ab.

norwegen60 18. Sep 2017 21:55

AW: Übergabe einer Klasse von EXE an DLL
 
Zitat:

Zitat von Zacherl (Beitrag 1381527)
Im Grunde nicht viel. Du müsstest dir für jedes Object alle Methoden, die über die Programmgrenzen hinweg aufgerufen werden in einem Interface deklarieren. Danach leitest du dein bestehendes Objekt nicht mehr von
Delphi-Quellcode:
TObject
, sondern von
Delphi-Quellcode:
TInterfacedObject
und
Delphi-Quellcode:
IMyInterface
ab.

Hier liegt eines meiner Verständnisprobleme. Eigentlich will ich ja gar keine Methoden über die Programmgrenzen hinweg aufrufen sondern nur Felder. Ausser wenn bei den Properties auch die Getter und Setter gemeint sind. Wäre auch ein
Delphi-Quellcode:
property Power: Realread FPowerwrite FPower;
betroffen?
Oder ein
Delphi-Quellcode:
  TMessValue = class(TObject)
    Load: Real;
    Power: Real;
  end;

Zacherl 18. Sep 2017 22:50

AW: Übergabe einer Klasse von EXE an DLL
 
Interfaces können leider ausschließlich Methoden besitzen. Zugriff auf Felder müsstest du dann alle über Getter/Setter kapseln. Ich würde allerdings mal behaupten, dass wenn du in deiner Klasse ausschließlich triviale Datentypen hast (String und Arrays sind davon ausgenommen) und die Klasse zudem keine Seiteneffekte in der VCL/RTL auslöst, solltest du relativ sicher sein. Höchstens irgendwelche RTTI Geschichten könnten dann noch Probleme bereiten.

jaenicke 19. Sep 2017 05:18

AW: Übergabe einer Klasse von EXE an DLL
 
Es gibt viele Stolpersteine, wenn man Klassen so über DLL-Grenzen hinaus benutzt. Das fängt schon bei einem simplen is bzw. as an, das nicht funktioniert. Das wird aber teilweise auch in den Quelltexten der RTL und VCL benutzt. Deshalb erlebt man da durchaus die eine oder andere Überraschung...

Die Umstellung auf Interfaces lohnt sich. Damit ist man zukunftssicher unterwegs und muss nicht mit Workarounds anfangen, wenn es Probleme gibt. Zumal die Fehlersuche im Zweifelsfall enorm Zeit kostet.

Dazu kommt, dass man die Schnittstelle zur DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.

Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.

Für die generischen Listen usw. haben wir z.B. Container mit Interface-Anbindung erstellt.

Ghostwalker 20. Sep 2017 09:58

AW: Übergabe einer Klasse von EXE an DLL
 
Ich häng mich jetzt einfach mal an. Hat das ganze schon jemand mal mit den "Advanced Records" probiert ?

norwegen60 20. Sep 2017 11:32

AW: Übergabe einer Klasse von EXE an DLL
 
Zitat:

Zitat von jaenicke (Beitrag 1381533)
Dazu kommt, dass man die Schnittstelle zur DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.

Für uns ist es keine Einschränkung, dass EXE und DLL immer in derselben Umgebung kompiliert werden müssen.

Zitat:

Zitat von jaenicke (Beitrag 1381533)
Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.

Auch das ist keine Einschränkung. Der Speicher, sprich erstellen und freigeben, wird immer nur in der EXE gemacht. Aktuell ist die Vorstellung, dass die EXE den gesamten Prüfablauf und die Felder für erwartete Ergebnisse generiert. Die DLL füllt dann diese Felder mit Messergebnissen. Im Beispiel die Power bei der vorgegebenen Prüflast.
Das wäre was anderes, wenn man auch die Intelligenz, den Prüfablauf zu generieren, in die DLL verlegen würde was wir aber vermieden haben um einen eindeutigen Master of the Class zu haben. Eine Einschränkung mit der wir leben können, wenn dadurch das Klassenhandling sicher ist.

jus 20. Sep 2017 18:46

AW: Übergabe einer Klasse von EXE an DLL
 
Zitat:

Zitat von jaenicke (Beitrag 1381533)
Es gibt viele Stolpersteine, wenn man Klassen so über DLL-Grenzen hinaus benutzt. Das fängt schon bei einem simplen is bzw. as an, das nicht funktioniert. Das wird aber teilweise auch in den Quelltexten der RTL und VCL benutzt. Deshalb erlebt man da durchaus die eine oder andere Überraschung...

Die Umstellung auf Interfaces lohnt sich. Damit ist man zukunftssicher unterwegs und muss nicht mit Workarounds anfangen, wenn es Probleme gibt. Zumal die Fehlersuche im Zweifelsfall enorm Zeit kostet.

Dazu kommt, dass man die Schnittstelle zur DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.

Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.

Für die generischen Listen usw. haben wir z.B. Container mit Interface-Anbindung erstellt.

Hallo,
die Auslagerung von Funktionen mit Objekten in ein paar eigenständige DLLs hatte ich auch schon mal vor gehabt, darum würde mich interessieren wie sowas ausschauen könnte. Könnte jemand ein kurzes Beispiel posten wie sowas ausschaut?

lg,
jus

Fritzew 20. Sep 2017 21:40

AW: Übergabe einer Klasse von EXE an DLL
 
Zitat:

Auch das ist keine Einschränkung. Der Speicher, sprich erstellen und freigeben, wird immer nur in der EXE gemacht. Aktuell ist die Vorstellung, dass die EXE den gesamten Prüfablauf und die Felder für erwartete Ergebnisse generiert. Die DLL füllt dann diese Felder mit Messergebnissen.
Da sind wir aber auch schon wieder beim gleichen Problem... Irgendwie müsst ihr ja sicherstellen das die Daten "Threadsafe" sind.
Meiner Meinung nach ist Euer Ansatz falsch. Wenn eine Dll so abhängig ist von der EXE, sprich gleicher Compiler Source etc. Dann schafft ihr nur zusätzliche Probleme.
Ich würde empfehlen im ersten Schritt das Threadsafe zu machen. Erst dann anschauen was man sinnvoll und unabhängig in eine DLL verschieben kann. Ich sehe sonst keinerlei Sinn in einer DLL.
Am einfachsten wäre eigentlich das benutzen von Packages in der Konstellation. Dafür sind die nämlich gemacht.


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

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