![]() |
AW: Übergabe einer Klasse von EXE an DLL
Deshalb besser Interfaces benutzen.
|
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? |
AW: Übergabe einer Klasse von EXE an DLL
Zitat:
Delphi-Quellcode:
, sondern von
TObject
Delphi-Quellcode:
und
TInterfacedObject
Delphi-Quellcode:
ab.
IMyInterface
|
AW: Übergabe einer Klasse von EXE an DLL
Zitat:
Delphi-Quellcode:
betroffen?
property Power: Realread FPowerwrite FPower;
Oder ein
Delphi-Quellcode:
TMessValue = class(TObject)
Load: Real; Power: Real; end; |
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.
|
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. |
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 ?
|
AW: Übergabe einer Klasse von EXE an DLL
Zitat:
Zitat:
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. |
AW: Übergabe einer Klasse von EXE an DLL
Zitat:
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 |
AW: Übergabe einer Klasse von EXE an DLL
Zitat:
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. |
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