TObject, DLL, DLL Freigabe

[himitsu]

Jupp, bei Klassen mußt du auf BPLs wechseln.

Wennn du Interfaces nutzt und nicht willst, daß die DLL vor Freigabe des Interfaces freigegeben wird, dann könntest du in dem Objekt eine eigene Instanz der DLL holen.
Im Contructor ein LoadLibrary.

Aber beim Freigeben gibt es ein "kleines" Problemchen, denn da müsstest du jetzt das FreeLibrary innerhalb der DLL aufrufen (im Destructor) aber dann würdest du ja den Coderücksprungpunkt löschen, auf den das FreeLibrary zurück will, womit es dann kannlt, bevor die DLL komplett verlassen wurde.
Man kann da aber einen Thread starten, welcher etwas verzögert die DLL und sich frei gibt. FreeLibraryAndExitThread (aber kein RTL-Thread, sondern nur eine "einfache" Thread-Prozedur, denn sonst bleiben eventuell Speicherlecks zurück ode es knallt dennoch, falls die DLL/RTL sich den Thread merkt und freigeben will, wenn sie freigegeben wird)

[haentschman]

Nachfrage:

Ich hätte noch als Übergabeparameter zur DLL eine generische TObjectList. (hallo DLL, mach mal die Liste voll) Wie gehe ich damit um? Da die Objekte nun zu Interfaces geworden sind geht ja nur TList. Die Interfaces werden dann in der DLL erzeugt und in die Liste gelegt.

Welche Probleme erwarten mich? 8-)

Zitat:

Wennn du Interfaces nutzt und nicht willst, daß die DLL vor Freigabe des Interfaces freigegeben wird

...die Frage ist doch, was passiert mit dem Inhalt des Interfaces bzw. der Liste mit den Interfaces beim Entladen der DLL? Bleibt das erhalten?

[himitsu]

Zitat:

Zitat von haentschman (Beitrag 1252021)

Zitat:

Wennn du Interfaces nutzt und nicht willst, daß die DLL vor Freigabe des Interfaces freigegeben wird

...die Frage ist doch, was passiert mit dem Inhalt des Interfaces bzw. der Liste mit den Interfaces beim Entladen der DLL? Bleibt das erhalten?

Das Interface geht "kaputt".

Der Speicher in der Liste wird vom Speichermanager der DLL freigegeben
und der Code, auf welchen die Funktionen des Interfaces zeigen ist weg da er ja in der DLL war.



Man könnte zwar absichtlich den Speichermanager zerschießen, damit er die "Speicherlecks" beim Beenden nicht freigibt,
oder man baut seine TList so, daß sie den Speicher z.B. direkt bei Windows holt und nicht über den Speichermanager geht,
oder man sorgt dafür, daß der Speichermanager nicht genutzt wird und stattdessen der Speichermanager der EXE verwendet wird (SharedMM),
aber es fehlt dann immernich der Code (alle Methoden, die man in dem Interface aufrufen kann), welcher die Liste verwaltet.

Die Liste müsste also in der EXE erstellt werden und alle Strings/Inhalte, dürfen nicht im Speichermanager der DLL liegen.
> Kein String, sondern nur WideString darf im Interface verwendet werden und auch sonst nichts, was im Speichermanader der DLL landen könnte.

[jaenicke]

Zitat:

Zitat von haentschman (Beitrag 1252021)

Ich hätte noch als Übergabeparameter zur DLL eine generische TObjectList. (hallo DLL, mach mal die Liste voll) Wie gehe ich damit um? Da die Objekte nun zu Interfaces geworden sind geht ja nur TList.

Würde ich so nicht sagen...
Ich habe dafür eine IInterfacedList<IMyObject> selbst geschrieben basierend auf der TList<IMyObject>.

Zitat:

Zitat von haentschman (Beitrag 1252021)

...die Frage ist doch, was passiert mit dem Inhalt des Interfaces bzw. der Liste mit den Interfaces beim Entladen der DLL? Bleibt das erhalten?

Das ist ja schon beantwortet, daher nur noch ein Hinweis:
Eine Möglichkeit wäre ein Factory-Interface, das du aus deinem Programm mitgibst und die Objekte erstellt. Die DLL muss diese dann nur über die Interfaces füllen und in die Liste hängen.

[haentschman]

Gut...
Dann ist es klar. Die DLL hat dann den gleichen Lebenszyklus zu haben wie die Klasse welche die Objekte / Interfaces / Listen hält. Das bedeutet ein klein wenig Umbau. :(

Danke.