Zitat von messie:

Ich dachte immer, Application.Processmessages erzwingt die Abarbeitung der Windows-Eventqueue.

1. Jeder Thread hat seine eigene MessageQueue
2. Greifst du auf nicht threadeigene Variablen/Objekte zu
3. ist es ja gerade der Sinn eines Threads. Die Messageabarbeitung im Hauptthread läuft ja nebenbei

Das Problem bei der Benutzung von Synchronize ist aber, dass der Thread erst dann weiterläuft, nachdem die Methode abgearbeitet wurde. Daher habe ich es ja bisher mit PostMessage probiert, damit der Thread sofort weiterlaufen kann.

Es handelt sich bei dem Thread um einen Kommunikations-Thread, der ständig Daten empfangen und senden soll, daher soll keine Zeit für das Updaten der GUI vom Thread verloren gehen.

Also die GUI muss upgedatet werden, wenn den den Thread switched. Das verstehe ich nicht. Oder bist du auf einem Pentium 1 Prozessor?

Die GUI muss aus dem Hauptthread upgedatet werden. Daher habe ich bisher eine WM_User-Botschaft verschickt, da ich dachte, diese würde im Hauptthread abgearbeitet. Daher auch Applikation.ProcessMessages im Thread.

Nur wird die GUI halt aus dem anderen Thread geupdatet. Das ist mein Problem.

Application.ProcessMessages verarbeiter die Nachrichten und zwar in dem Thread, wo es aufgerufen wird.
wenn du also Application.ProcessMessages in einem Thread aufrufst, dann werden die Nachrichten auch in diesem Thread abgearbeitet und mit etwas Glück zankt sich dann die Nachrichtenverarbeitung des Programms mit der im Thread auch noch.

also Application.xyz hat nichts in einem Thread zu suchen.

Windows lässt gar nicht zu, dass ein Thread für einen anderen Fensternachrichten abarbeitet. Jeder Thread erhält nur die Nachrichten für seine eigenen Fenster.

ok, dennoch nutzt er dann die Nachrichtenverarbeitung des Hauptthreads, auch wenn er damit die Nachrichten eines anderen Thread abarbeitet

Wie kann ich dann bitte ohne ein Einsatz von Synchronize den Hauptthread dazu bewegen, die GUI zu aktualisieren?