Dynamisch geladene DLL blockiert Explorer

[Tobias Schreck]

Hallo werte Community,
ich habe ein Problem/Phänomen, an dem ich gerade graue Haare bekomme, ich hoffe jemand von euch kann mir helfen:

Ich habe eine simple Test-Anwendung mit einem Hauptfenster, welche auf Buttondruck eine ebenfalls simple DLL lädt, weitere Funktionen o. ä. werden nicht ausgeführt. Laden, entladen usw. funktioniert zunächst einwandfrei.

Sobald ich nun die Unit Forms in die Uses-Liste der DLL aufnehme, und über den Button der Anwendung die DLL lade, ist für rund 30 Sekunden der Explorer sowie Taskbar blockiert! Konkret lässt sich das so reproduzieren, indem ich nach Laden der DLL Windows+E drücke, um den Explorer zu starten, aber nix passiert, die Taskbar ist auch tot. Nach Ablauf von 20-30 Sekunden plötzlich poppt der Explorer dann plötzlich auf. Die Applikation sowie die DLL reagieren übrigens währenddessen, stehen also nicht!

Wenn ich die DLL statisch verlinke, tritt dieses Phänomen übrigens nicht auf. Ich bin aber auf dynamisches Laden angewiesen. Desweiteren benutze ich zwar nicht direkt Formulare innerhalb der DLL, aber die Unit Printers benutzt auch Forms... :-((

Gibts da irgendein Problem mit der Message-Abarbeitung oder so?

Ich hoffe es hat jemand eine Idee!!!?

Danke und Gruß,
Tobias

[Tobias Schreck]

Schade, dass niemand bisher eine Idee dazu hat!

Mal anders gefragt: Die Anwendung soll beim Programmstart besagte DLL laden, aber zur Laufzeit auch ggf. die DLL entladen und nach kurzer Wartezeit die DLL wieder laden können. Selbständig, d. h. dazu ist natürlich ein Thread notwendig. Kann das o. g. Problem ggf. durch die Verwendung des Threads zustande kommen, und was könnte man dagegen tun?

Danke vorab,
Tobias

[Bernhard Geyer]

Kann das o. g. Problem ggf. durch die Verwendung des Threads zustande kommen,

Ja, kann sehr gut der Fall sein. Mit der verwendung von Forms in der Uses-Anweisung wird die global Instanz Application angelegt. Da dieses zur interaktion mit Windows (Message-Queue etc.) ein verstecktes Fenster anlegt könnte es hier Probleme geben da mal alles was mit GUI-Controls in der VCL zu tun hat immer im primären Thread der Anwendung durchführen sollte.

und was könnte man dagegen tun?

Verzichte auf den Thread. Da entladen wird wohl nicht zu lange dauern das es nicht im Hauptthread geschehen darf.

[Tobias Schreck]

Hallo Bernhard,

danke für Deine Antwort! Evtl habe ich da nur eine Gedankenblockade, aber mir fällt gerade keine sinnvolle Struktur für ein Redesign ein. Die Anforderung sieht im Augenblick zumindest so aus:

- Die DLL kann sowohl von einem Dienst als auch von einer gewöhnlichen Applikation aus geladen werden
- Wird die DLL aus der GUI-Applikation gestartet, sollen auch Statusinfos aus der DLL geholt und im Fenster der GUI-App angezeigt werden. Dies erledige ich über TCP/IP-Kommunikation, da...
- Eine weitere GUI-App, welche als Viewer für den Dienst/Service gestartet werden kann, ebenfalls die Statusinfos aus der DLL erhalten und anzeigen können soll.

Falls Du/jemand eine Idee hat, wie man das pfiffiger erledigen kann, wäre ich sehr dankbar...

Gruß,
Tobias