Man könnte hier doch einen Timer nutzen um den aktuellen Zustand des Threads in der Statusbar anzuzeigen.

Der Timer wäre damit nicht in dem Thread sondern in der GUI.

Alternativ kann man auch eine message an das Hautpfenster von Thread aus schicken, asynchron mit PostMessage. Diueses kann dann updaten wenn es idle ist.

Laut der Antwort in String data from Thread to Main koennte man doch die Aktion der Status-Anzeige .Queue'en, oder nicht?

Kann man infolge dessen nicht auch den Anstoss eines TTimers aus einem TThread ohne AV-Gefahr .Queue'en?

Wenn Threads irgendwas nach außen zu funken haben, dann bekommen sie callbacks, die man entsprechend synchronisieren kann.

Wenns komplexer wird, dann einfach OTL oder so nutzen, da gibt es zig Mechaniken.

Zitat von hzzm:

Laut der Antwort in String data from Thread to Main koennte man doch die Aktion der Status-Anzeige .Queue'en, oder nicht?

Genau - wobei ich lieber den eigentlichen Wert per callback rausgeben würde, das string zusammentackern kann dann dort gemacht werden.

Mit TTimer geht es nunmal nicht im Thread, aber natürlich kann man SetTimer auch innerhalb eines Threads benutzen.
* man muß nur ein Message-Windows im Thread erstellen und da drin einen Timer aktivieren
* und man muß im Thread natürlich auch auch die Window-Messages verarbeiten, vor allem WM_TIMER

Zitat von himitsu:

Mit TTimer geht es nunmal nicht im Thread

Mein Problem ist momentan eher, dass ich ausserhalb des Threads einen riesigen Timer-gesteuerten Ablauf je nach Thread-Ergebnis an- oder ausschalten muss.
Den kann/moechte ich gar nicht komplett im Thread unterbringen, da dieser Ablauf noch an zig anderen Stellen im Code regulaer verwendet wird.

Ich muesste den Timer ausserhalb eben nur aus dem Thread anstossen.

Darf ich das mit .Queue?

TThread.Synchronize oder TThread.Queue ... wird beides im Hauptthread ausgeführt.

SendMessage und PostMessage ebenso (wenn das zugehörige Window im Haupthtread erstellt wurde) und PostThreadMessage sowieso.