Ich habe hier im Forum irgendwo mal gelesen, dass man, selbstverständlich, keine GUI-Änderungen in einem Thread abarbeitet. Und wenn, dann mit Synchronisation.

Ich habe einen Thread der bei einem längeren Prozess meine GUI immer anpasst. Genauer gesagt Captions, ProgressBars usw.
Ich habe hier auch irgendwo mal gelesen, dass man zum Beispiel im Thread A gewisse Variablen setzt (sagen wir mal Position der ProgressBar in einer Int-Variablen) und die in einem Timer auf der Mainform ausließt und setzt.

Weg vom Thread, der meine ProgressBar setzt und hin zum Timer auf der Mainform ja oder nein? Welche vorteile hätte das für mein Programm?

Der richtige Weg wäre den Haupt-Thread mit der UI frei von Jobs zu halten.
Die Jobthreads synchronisieren die Progressbars und Caption selbst mit TThread.Synchronize(nil, ...)

Verstehe ich gerade nicht so ganz.
Wäre es also falsch einen Timer Variablen lesen zu lassen und die GUI verändern zu lassen?
Stattdessen alles im Thread mit Synchronize lassen?

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.

Oh, da habe ich eine andere Auffassung als der schöne Günther.
Ich haue die Meinung mal noch raus, mal sehen, wie das die Profis sehen...
(Der zweite Thread ist natürlich aus meiner Sicht dann auch überflüssig.)

---
Wenn Du in einer Timerbehandlung ständig MyThread.ProgressPosition ausliest und den Wert übernimmt, dann macht das der Timer ständig.
Er kann ja nicht wissen, ob es im Thread einen Fortschritt gab.
Er kann auch nicht wissen, ob der Thread gerade steht oder vielleicht schon terminiert ist.

Der Thread weiß viel besser, ob und wann eine Aktualisierung der Darstellung erforderlich ist. Und wenn der Thread fertig ist entfällt die Aktualisierung automatisch, ohne dass Du in einem Timer o.ä. noch etwas abschalten musst.

Also würde ich das im Synchronize belassen.
---

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.