Den zweiten Thread kann man sich dann echt sparen, der Teil wäre dann, wie gesagt, eigentlich doch in einem Timer super aufgehoben.

Was hätte der Timer denn dann für einen Vorteil gegenüber dem Thread?

Da oben mit der while-Schleife hab ich übrigens Quatsch geschrieben. Hab mir dem alten Code nochmal angesehen und funktioniert alles bestens mit "Wenn du mich nicht siehst, ändere mich auch nicht" (hat halt nur den Nachteil, dass man bei den Aero-Vorschaufenstern keine Änderung mehr wahrnimmt).

Zitat von Jim Carrey:

geht momentan aber nicht, da ich nach dem Start der "Arbeit" eine while-Schleife habe die auf die Beendigung der Threads wartet.

wartet der Haupt-Thread auf das Ende vom Job-Thread in einer While Schleife, mit Sleep() und ProcessMessages()?.

Zitat von Jim Carrey:

Was hätte der Timer denn dann für einen Vorteil gegenüber dem Thread?

Im Timer Event kann sich mit dem UI ohne Synchronize() unterhalten. Der Thread nicht.

Zitat:

wartet der Haupt-Thread auf das Ende vom Job-Thread in einer While Schleife, mit Sleep() und ProcessMessages()?.

Beides. Ich benutze eine gut angepasste Sleep-Version von negaH (so heißt er hier im Forum).

Zitat:

Im Timer Event kann sich mit dem UI ohne Synchronize() unterhalten. Der Thread nicht.

Bringt das auch Performance-Vorteile (weniger CPU-Last etc) wenn man das Synchronize() nicht mehr braucht?

Polling (und nichts anderes soll der Timer ja anscheinend tun) bringt wenn überhaupt nur selten Performancevorteile.

Zitat von Jim Carrey:

Zitat:

Im Timer Event kann sich mit dem UI ohne Synchronize() unterhalten. Der Thread nicht.

Bringt das auch Performance-Vorteile (weniger CPU-Last etc) wenn man das Synchronize() nicht mehr braucht?

Ja, der Thread läuft immer. Der Timer nur, wenn er getriggert wird.
Man könnte es noch etwas optimieren, wenn der Thread den Timer erst einschaltet, wenn es auch eine Änderung gab.
Also im dem Stil:

markieren

Delphi-Quellcode:

TThread.Synchronize(nil, procedure ()
 begin
   MainForm.Progress := Self.Progress;
   MainFrom.Timer.Enabled := True;
 end);

Der Timer triggert dann nach der Zeit und schaltet sich selbst erst einmal wieder ab.

Wie wäre es mit TThread.Queue?

Bevor ich mich Queue widme eine Verständnisfrage:
- muss ich auch das Ändern des Hints und das Ändern des Icons des Tray-Icons meiner Anwendung sychronisieren?
- muss ich auch einfaches "besorgen von Informationen" synchronisieren? Zum Beispiel das Besorgen der Caption eines Labels?

Zitat von DeddyH:

Wie wäre es mit TThread.Queue?

Der Führt dann die Methode immer aus. D.h. bei jedem noch so kleinen Progress, wird die Methode gerufen.
Die Timer-Lösung macht ein Update nur einmal in der vorgegebenen Zeit, egal wie oft der Timer eingeschaltet wurde.
Das bringt ein wenig "Ruhe" rein