Nein, das wäre besser, denn somit hat dein Thread nur z.B. einen Wert "FortschrittInProzent" und muss sich gar nicht mit solchen Feinheiten wie Progressbars und ähnlichem auseinandersetzen. Außerdem kannst du mit dem Timer das Aktualisierungs-Intervall für die Anzeige komfortabel und unabhängig vom eigentlichen Thread regeln. Auch Dinge wie "Wenn die Anwendung minimiert ist brauche ich die Anzeige auch nicht zu aktualisieren" sind dort gut untergebracht. Packst du das alles in deinen Thread siehst du dort bald den Wald vor lauter Bäumen nicht mehr weil er sich nur noch zu 10% um seine eigentliche Aufgabe kümmert und der Rest mit eigentlich ganz anderem Anzeige-Kram vollgestopft ist.

Ok verstanden. Dazu muss ich was sagen, hatte ich vergessen!

Ich habe zwei Threads. Der eine macht die ganze Arbeit die zu erledigen ist und der zweite ließt die Variablen aus, welche im ersten gesetzt werden.
Und nur wenn der eventuelle neue Wert der ProgressBar größer ist als der alte, wird auch tatsächlich die GUI verändert.

Zitat:

"Wenn die Anwendung minimiert ist brauche ich die Anzeige auch nicht zu aktualisieren"

Würde ich verdammt gerne machen, geht momentan aber nicht, da ich nach dem Start der "Arbeit" eine while-Schleife habe die auf die Beendigung der Threads wartet.
Ich weiß, das ist harter Tobak und echt nicht schön aber leider noch ein Relikt aus früheren Zeiten meines Codes. Werde ich irgendwann mal abändern.

Edit:
ich sehe gerade dass ich sowas doch eingebaut habe. Aber ich prüfe nicht auf "bist du minimiert" sondern "bist du im Systembereich versteckt".

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.