Also den Sinn eines zweiten Threads, um die GUI zu aktualisieren erschließt sich mir nicht so ganz. Und mit einem Timer zu guckcjen wie weit der Thread ist, ist auch etwas sinnbefreit.

Der Thread weiß doch am besten wie weit er ist. Also kann er auch der GUI seinen Fortschritt mitteilen (Synchronize, Events, Nachrichten). Wenn ich ein Paket erwarte gehe ich doch auchnicht alle fünf Minuten vor die Tür und gucke, ob der Paketbote vor der Tür steht. Dazu habe ich eine Türklingel (Event, Nachricht), die mir sagt, dass der Paketbote vor der Tür steht.

Hier gibt es nich ein etwas älteres Tutorial zu Threads von mir: http://michael-puff.de/Programmierung/Delphi/Tutorials/

Ist ein Timer nicht auch eigentlich ein Thread? Somit wäre es gleichwertig, ob ich per 2. Thread oder Timer den Fortschritt des 1. Thread "überwache".

Da ein Thread ja eher Teil der Business-Logik ist, ist es mMn gar nicht so verkehrt, dass der Arbeiter-Thread nicht selbstständig die GUI ändern kann. Auch sollte ein Thread nicht unbedingt selbst entscheiden können müssen, wann die GUI aktualisiert werden muss.

Insofern find ich eine Kombination aus der von ConnorMcLeod vorgeschlagenen Event-Property, plus einer Info wann diese feuern soll (z.B. alle 10% Fortschritt) die man dem Thread von Aussen mitgibt in diesem Fall sinnvoll. Dazu dann ruhig auch eine von Aussen abfragbare Property, die den aktuellen Fortschritt o.ä. ausgibt und schon ist man flexibel, wie man den Thread nutzen möchte.

Für mich stand damals im Vordergrund den Arbeiterthread zu entlasten.
Ich wollte Arbeit und Anzeige trennen was bis heute gut klappt.

Aber da ich irgendwo in diesem Forum mal gelesen habe, dass man dafür eigentlich einen Timer nimmt, dachte ich frage ich mal nach. Aber da gehen die Meinungen ja stark auseinander.

Ein Timer ist kein Thread! Ein Timer wird durch Windows Nachrichten ausgelöst (WM_TIMER).

Zitat von Luckie:

Ein Timer ist kein Thread! Ein Timer wird durch Windows Nachrichten ausgelöst (WM_TIMER).

Das ist mir vollkommen klar. Wenn du den Verlauf des Themas gelesen hättest wüstest du auch warum ich Timer und Threads in einen Topf werfe.

Zitat von stahli:

...

Vielen Dank für die ausführliche Antwort.

Die Timerbehandlung ist kein Thread.

Der Mainthread rödelt ständig in einem Loop und schaut, was zu tun ist.
Er prüft, ob Tastaturnachrichten anliegen und gibt diese an die Controls weiter.
Dann schaut er, ob OnIdle etwas zugewiesen ist und führt das aus, wenn sonst nichts zu tun ist.
Und er schaut, ob Timermessages anliegen.
Dann behandelt er diese, indem die zugewiesene Ereignisbehandlung ausgeführt wird.
Dauert diese 2 Minuten, hängt die GUI so lange.

Ob Du ShowProgressValue(Value) jetzt in einer Timer-Behandlung ausführst oder synchroniert aus dem Arbeitsthread aufrufst, nimmt sich für die GUI nicht viel.
Lediglich der Thread wird bei Synchronize-Nutzung in dem Moment für ein paar Millisekunden unterbrochen, bis der Mainthread die Änderung zulässt. Diese Änderung läuft dann genau so im Mainthread-Loop wie die oben skizzierte in einer Timerbehandlung.
Der Arbeitsthread sagt dann halt nur: Ich will mal eine Änderung veranlassen, sag mir, wenn ich kann... Ich warte mal so lange...

Bei jeder Lösung müssen beide Prozesse irgendwie aufeinander abgestimmt werden. Du musst entscheiden, welchen Aufwand Du betreiben willst und welche Performanceanforderungen Du hast.
Solang Deine Progressaktualisierung Dein Projekt nicht ausbremst würde ich die einfachste Lösung wählen.
Wenn das System ausgebremst wird (bei extrem vielen, extrem schnellen Änderungen) dann würde ich einfach nur jede 100. Änderung an die Gui geben und fertig.

Wenn Du vom Thread aus über Synchronize Deine Gui in Teilen aktualisierst heisst das nicht, dass Du Logik und GUI vermischt.

Man kann das noch klarer trennen, aber man sollte auch Aufwand und Nutzen abwägen.

Anscheinend bin ich doch nicht der Einzige, der dieses Timer-Geraffel nicht versteht, das beruhigt mich *puh*.

Zitat von Luckie:

Wenn ich ein Paket erwarte gehe ich doch auchnicht alle fünf Minuten vor die Tür und gucke, ob der Paketbote vor der Tür steht. Dazu habe ich eine Türklingel (Event, Nachricht), die mir sagt, dass der Paketbote vor der Tür steht.

Aber es kann den den Hauptthread extrem nerven, wenn der Postbote jede Millisekunde an der Tür schellt, nur weil er gerade wieder ein 0,000001% Päckchen hat. Das mag ja ganz ganz nett sein, aber dann ist der Hauptthread doch wieder nur mit dem Postbosten beschäftigt. Daher hat die Lösung: Selbst und in regelmäßigen Zeiten an die Tür zu gehen und dann auf ein mal alle Päckchen rein zu holen, nicht schlecht.

Dann sagt man dem Boten eben, dass er nur bei jedem vollen Prozent klingeln soll. Das ist doch keine Raketentechnik.

Zitat:

Daher hat die Lösung: Selbst und in regelmäßigen Zeiten an die Tür zu gehen und dann auf ein mal alle Päckchen rein zu holen, nicht schlecht.

Genau. Und das macht mein zweiter Thread nebenher immer, wenn die ausgerechneten Prozent der verarbeitung höher sind als die davor UND wenn eine gewisse Zeitspanne zutrifft.