Hi,

ich beschäftige mich gerade das erste mal mit dlls. Es geht um die exif unit aus dem forum: www.delphi-forum.de/...2&highlight=exif

Ich möchte das gerne in eine dll umsetzen. Aber im Programm wird ja ein Objekt vom Typ TExif erzeugt. Wie mache ich das wenn ich das in einer dll habe? Die dll habe ich schon. Aber im programm weis ich jetzt nicht wie ich das objekt erstellen und so nutzen kann als wenn ich die exif.pas unit nutzen würd.

danke schonmal!!

Das war genau der Knackpunkt von puren DLLs. Die konnten ebend nur Funktionen exportieren und dann lag es beim programmierer mit Pointern hin und her zu reichen und wer später den Speicher freigibt und so. Der direkte Weg für sowas heißt wohl ActiveX heutzutage.

Ansonsten kannst du doch einfach das Objekt mit einem Pointer übergeben. Aber vorsicht, dann geht es nämlich mit solch netten Sachen los wie "wem gehört der Speicherbereich und wer verwaltet ihn?"

ich empfehle, implementiere in der DLL die kompletten Methoden als auch die Klassen und
exportiere lediglich die Funktionen die den Header zurückgeben (ggf. ein einfacher Record).

zum beispiel



in deinem Hauptprogramm musst du dann nur diese drei Funktionen aufrufen.

es ist "unelegant", auf Klassen zurückzugreifen, die eigentlich nicht zur Hauptklasse gehören.

grez
msch

digi_c hat folgendes geschrieben:

Ansonsten kannst du doch einfach das Objekt mit einem Pointer übergeben. Aber vorsicht, dann geht es nämlich mit solch netten Sachen los wie "wem gehört der Speicherbereich und wer verwaltet ihn?"

Viel interessanter: Das ABI ändert sich (spätestens bei der Verwendung eines anderen Compilers) und dir fliegt deine Anwendung mit einigen AVs und/oder unvorhersehbarem Verhalten um die Ohren.
Die für Borländer richtige Methode: "BPL"s
Die compilerunabhängige richtige Methode (also die richtigere ): [url=www.delphipraxis.net/post29930.html#29930] Interfaces[/url]
Die full-blown Methode: DCOM/CORBA-Server

@tommie-lie
ich vermute du meinst API.

Allerdings wäre die Kapselung so wie ich sie vorgeschlagen, vollkommen unabhängig vom Compiler etc.
Die DLL exportiert 3 Funktionen, wie sie diese realisiert ist wurscht, und wenn einmal ok dann auch noch
in 10 Jahren, da sich hier nicht ändern kann - wäre ja grausam, wenn MS die Methoden zum statischen oder
dynamischen Linken verändern würde.
grez
msch

MSCH hat folgendes geschrieben:

ich vermute du meinst API.

Nein. Hätte ich das gemeint, hätte ich es geschrieben, "B" und "P" liegen auf der Tastatur weit genug entfernt.
en.wikipedia.org/wik...ion_binary_interface

MSCH hat folgendes geschrieben:

Allerdings wäre die Kapselung so wie ich sie vorgeschlagen, vollkommen unabhängig vom Compiler etc.

Aber sie wäre nicht schön, da du auf Teile der Objektorientierung verzichtest. Warum erst die Mühe machen und in der DLL eine saubere Klassenhierarchie bauen und nachher trotzdem alles prozedural abwickeln?
Du tauschst über das Record lediglich Informationen aus. Du hast keine Methoden in einem Record. Und wenn du doch welche hast (Delphi2006, IIRC), hast du wieder die gleichen Probleme wie vorher auch, nämlich daß sich das ABI ändern kann.

aha, aber das ABI ist standartisiert (the Intel Binary Compatibility Standard (iBCS))**egal**

Zurück zur Frage die da lautet, wie man das ganze Zeigergeraffe umgeht, und das wäre imho die
beste Variante. Kapsle eine Klasse (egal ob DLL, BPL, oder ActiveX oder oder oder) und greife
auf exportierte Funktion, Daten (oder Properties im klassischen Sinne) zurück.

Das ist ja auch der Vorteil; ich implementiere eine Klasse die Eigenschaften veröffentlicht,
auf die ich (von woanders) zugreifen kann; wie im Schluss diese Implementation erfolgt, ist
Sache und Eigenschaft der Klasse.

Eine Dll wird im klassischen Sinne immer Procedural abgewickelt,schau dir mal die Unit Windows oder
Types an, alles klassiche Funktionen die statisch gelinkt werden. Da ist nix mit Klassen.

grez
msch

MSCH hat folgendes geschrieben:

aha, aber das ABI ist standartisiert

Nein.
1. Da steht "such as"
2. G++ ändert gelegentlich sein ABI
3. Objekte aus DLLs zu exportieren funktioniert aus genau dem Grund nicht sauber, weil jeder Compiler frei ist, sein eigenes ABI zu benutzen
4. Delphi kennt allein mehrere Calling Conventions (pascal/register, stdcall, cdecl). VB nur eine: stdcall.
Edit:
5. Es gibt für ABIs keine Art zu stehen. Dafür gibt es aber Duden.

MSCH hat folgendes geschrieben:

Zurück zur Frage die da lautet, wie man das ganze Zeigergeraffe umgeht, und das wäre imho die beste Variante. Kapsle eine Klasse (egal ob DLL, BPL, oder ActiveX oder oder oder) und greife auf exportierte Funktion, Daten (oder Properties im klassischen Sinne) zurück.

Man muss immer auf exportierte Funktionen zurückgreifen. Um die Frage zu beantworten, wie man das Zeigergeraffe umgeht: Mit Interfaces oder einem BPL. Dann ist es entweder compilerunabhängig oder ohnehin nur für Borland-Compiler ausgelegt.

MSCH hat folgendes geschrieben:

Das ist ja auch der Vorteil; ich implementiere eine Klasse die Eigenschaften veröffentlicht, auf die ich (von woanders) zugreifen kann; wie im Schluss diese Implementation erfolgt, ist Sache und Eigenschaft der Klasse.

Du hast die Eigenschaften eines Interfaces erkannt. Benutze es doch auch

MSCH hat folgendes geschrieben:

Eine Dll wird im klassischen Sinne immer Procedural abgewickelt,

Geht nicht anders, da abwärtskompatibel. Sobald du ein Interface zurückgibst hast du aber objektorientierte Eigenschaften. Du kommst für ein beliebiges Plugin mit zwei Funktionen aus: CreateInstance() und DestroyInstance(). Erstere liefert dir ein Interface auf ein erzeugtes Objekt und der Rest ist komplett objektorientiert.

MSCH hat folgendes geschrieben:

schau dir mal die Unit Windows oder Types an, alles klassiche Funktionen die statisch gelinkt werden. Da ist nix mit Klassen.

Woher das wohl kommt? Nicht etwa, weil Microsoft auch auf prozedurale Sprachen Rücksicht nehmen muss? Wäre die Windows-API komplett objektorientiert würdest du sämtliche Pascal- und C-Programmierer inklusive aller anderen Programmierer prozeduraler Programmiersprachen ausschließen. Aus diesem Grund existiert (D)COM(+).
Schau dir mal das .NET-Framework an. Alles Klassen. Da ist nix mit prozeduralem Code.

oh man.. jetzt bin ich ja noch ratloser als vorher... also sollte man es sein lassen eine dll zu schreiben die ein objekt enthält oder wie? also lieber ausschließlich dll die nur fkt bzw proceduren enthalten?! ...ok... trotzdem danke..

Flash106 hat folgendes geschrieben:

also sollte man es sein lassen eine dll zu schreiben die ein objekt enthält oder wie?

Nein, nicht im Geringsten. Siehe mein erster Beitrag hier im Thread. Das sind die drei bekannten Standardlösungen für sowas. Sicherlich gibt es noch einiges mehr an proprietären oder selbstgestrickten Lösungen. Man könnte sich beispielsweise auch vorstellen, etwas SOAP-artiges lokal zurechtzufriemeln und seinen Objektaustausch darüber zu gestalten. Alles ist möglich

Uiuiii wer wird denn gleich aufgeben

Aber das bewegen über Prozess,Programm Grenzen hinweg UND erhalten der OOP Funktionalität ist schon ein bißchen kompliziert und es gibt ebend viele Lösungsansätze.

Mit Interfaces habe ich nur theoretische Erfahrungen. Würde man dan eine Art shared/global/öffentliche Unit machen in der die Interfaces zum Ansprechen dieser Klasse drin sind machen? Müsste man da per Hand die Methoden der Klasse übernehmen?

digi_c hat folgendes geschrieben:

Würde man dan eine Art shared/global/öffentliche Unit machen in der die Interfaces zum Ansprechen dieser Klasse drin sind machen?

Entweder das, wenn du welche für jede Sprache machen willst, oder du schreibst eine Typbibliothek (.tlb), die viele IDEs und Tools in eine brauchbare Unit/Headerdatei übersetzen können. Die "Sprache" dafür ist die Interface Definition Language, IDL, und du definierst darin dein Interface so, wie du es im Code tust. Vielleicht gibt es sogar Tools, die aus einer Unit mit Interface eine Typbibliothek erzeugt, aber wenn ich mich richtig erinnere kann zumindest die Personal-Edition der alten Delphis (< das nicht (oder ich habe es nie rausgefunden, wie es geht ).