Hallo,

ich habe eine DLL geschrieben, welche unter Umständen eine Form mit VCL Komponenten generiert und dargestellt.
Wie ich gelesen habe, dürfen VCL Komponenten nicht ohne weiteres außerhalb des Main Threads der Applikation verwendet werden.

Was geschieht denn nun, wenn die DLL Funktion, welche die Form generiert, in einem Thread aufgerufen wird? Muss ich in der Funktion irgendwelche Maßnahmen treffen?

Vielen Dank

Ja, hier musst du so einige Maßnahmen treffen.
Warum willst du die Form in einem extra Thread darstellen?

Also, es ist so, dass ich bei einer Funktion unter Umständen einfach eine Form generiere, welche ein paar Informationen darstellt. Diese generiere ich ganz normal in der DLL. Dort also nicht in einem extra Thread.

Wenn ich diese DLL nun an andere Programmierer weitergebe, kann es ja sein, dass die diese Funktion in einem extra Thread aufrufen. Aus welche Früdnen auch immer. Muss ja nicht unbedingt sein, könnte aber. Das weiss ich ja nicht. Deswegen die Frage...

Du brauchst mindestens eine Messageschleife. Ich würde aber generell bezweifeln, dass hier Windows so einfach mitmacht.

Das solltest du in der Dokumentation zu dieser DLL verbieten. Du kannst ja auch keinen TWebbrowser in einem Thread instanzieren. Das ist einfach so, und das sollte jeder, der deine DLL benutzt beachten.

Das Problem bei VCL-Objekten und Threads ist hauptsächlich die Nachrichtenschleife und dass, das Application Object welches im inneren öfter mal Verwendung findet von einem anderen Thread erzeugt wurde als die später erzeugten Objete des Threads.
Wenn du die DLL erst in deinem Thread lädst (LoadLibrary) hast du keinerlei Probleme weil dann die DLL im Context des Threads geladen wurde und somit das ApplicationObject etc. alles in diesem Threadcontext erstellt wird. Entsprechend ist für die DLL der Hauptthread der von der sie geladen wurde.

@SirThornberry: Leider weiss ich nicht wie die DLL später eingebunden wird, ob statisch, oder dynamisch

Bei mir haben sich drei Fragen aufgetan:

1. Also es ist so, dass es sich lediglich um ein Fenster mit einem Image und einem Label handelt. Das Label hat einen festen Text, welcher nicht geändert wird.
Darf solch eine (VCL-) Fenster (über eine DLL Funktion) auch nicht in einem Thread aufgerufen werden? Es wird ja nichts Aus- oder Eingegeben bzw. Daten ausgetauscht



2. Zum debuggen gebe ich mir auf einem zweiten Label zwei Werte welche sich zur Darstellungszeit des Fenster ändern aus. Bezogen auf das was SirThornberry geschrieben hat: Wäre es eine Lösung, wenn ich jeweils nach dem Ändern des Textes des Labels Application.ProcessMessages aufrufe?



3. Wäre eine Lösung für mich, das Fenster nonVCL zu generieren? ... und wenn ja, ist das aufwändig?

zu 1) Es kann funktionieren. Ich hatte mal ein Programm geschrieben, in dem man beliebig viele Fenster erstellen konnte. Jedes Fenster beinhaltete ein Socket. Und die habe ich komplett in Threads ausgelagert. Und das Programm stürzte ständig mit komischen Fehlern ab. Zudem waren die Formulare meist in ihrer Größe etwas anders, als ich es wollte.
Dann habe ich die Sockets in den Threads gelassen und das zugehörige Fenster in den Mainthread geholt. Plötzlich ist alles in Ordnung.
Es ist deine Entscheidung, ich würde davon abraten. Ich kann dir auch leider nicht sagen, warum und wieso da Fehler auftraten. Und ob man das verhindern kann.

2. Nein. Application ist ein globales Objekt. Das funktioniert in einer DLL eher weniger. Mna könntes es vielleicht hinbiegen, dass die Messageschleife funktioniert. Dazu muss man aber TAplication vom Inhalt her kennen. Und was macht man dann, wenn die DLL doch im Mainthread gestartet wird.

3. Vielleicht, da ich nicht weis, wo die Fehler auftreten, will ich es nicht ausschließen. Ein Fenster mit Label (ich würde hier StaticText nehmen) ist wahrscheinlich in jedem nonVCL-Tut enthalten.

4. Du könntest auch über eine ActiveXForm nachdenken. Da habe ich aber keine Erfahrung.

=> Wie gesagt, du machst dir nur Probleme damit. Was soll es für Gründe geben (außer Spielerei) die Grafik aus dem Mainthread herauszunehmen?

Naja, der Grund ist folgender:
Die Funktion wird dazu verwendet einen DSP per USB zu pollen. Ist unschön, aber lässt sich durch den Anwendungsfall nicht ändern. Nun kann es sein, dass der DSP (aus welchen Gründen auch immer) rebootet. Das heißt er ist nach einigen Sekunden wieder da. Wenn dies passiert, muss ich in der Funktion solange warten (ich darf nicht vorher aus der Funtion zurückkehren) bis er wieder da ist.

In dieser Zeit möchte ich eine Meldung auf dem Bildschirm anzeigen.

Also habe ich mit nonVCL wohl am meisten Chancen!? Ich meine 'messagebox' darf man doch auch bedenkenlos verwenden, oder?

PS: Teile diese Posts finden sich auch hier wieder