Code vom Thread in einen Timer umziehen?

[Jim Carrey]

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?

[DeddyH]

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

[Bambini]

Zitat:

Zitat von Jim Carrey (Beitrag 1351953)

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:

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.

[DeddyH]

Wie wäre es mit TThread.Queue?

[Jim Carrey]

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?

[Bambini]

Zitat:

Zitat von DeddyH (Beitrag 1351958)

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 ;-)

[Bambini]

Zitat:

Zitat von Jim Carrey (Beitrag 1351960)

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?

Ja und Ja.

[DeddyH]

Ich habe das Gefühl, ich verstehe die Problemstellung nicht richtig, oder andere haben ein eigenes Verständnis von Threads. Ich persönlich war zumindest noch nie in der Verlegenheit, einen Thread pollen zu müssen, das kommt mir so "von hinten durch die Brust ins Auge" vor.

[Der schöne Günther]

Und genau das ist der Punkt den ich meine. Siehst du wie aufwändig und fummelig das jetzt schon wird? Lass den Thread die eigentliche Arbeit machen, mach deine Oberflächen-Aktualisierungen in einem Timer und du bist schon fertig. 8-)

[ConnorMcLeod]

Mein Senf dazu:

Gib dem Arbeiterthread ein Event-Property.
Definiere im Form eine Aktualisierungsprozedur.
Weise diese Aktualisierungsprozedur dem Thread-Property zu.
Lass den Thread entscheiden, ob sein Zustand eine Aktualisierung rechtfertigt. Wenn ja, dann das Property (die Aktualisierungsprozedur) mittels Synchronize aufrufen.
In der Aktualisierungsprozedur prüfst Du, ob die Form sichtbar ist und machst die Aktualisierungen oder nicht.

Damit ist erreicht, daß dem Thread die Form nicht bekannt sein muß und es gibt eine klare Zuständigkeitstrennung.