Blub (siehe Seite 3)

Zitat von Glados:

Geht das nicht besser als mit WM_USER + N; ?

Wenn du bei PostMessage bleiben willst, nein. Ich würde TThread.Queue verwenden. Das ist wesentlich besser lesbar und deutlich flexibler.

Zitat:

Wenn du bei PostMessage bleiben willst, nein. Ich würde TThread.Queue verwenden. Das ist wesentlich besser lesbar und deutlich flexibler.

Aber synchronisiert Queue nicht auch irgendwo wieder das Hauptformular komplett?

Es ist besser lesbar und dafür gibt es 100 Punkte mehr als für PostMessage. Aber PostMessage, muss man leider sagen, ist wesentlich performanter wenn man das mehrere Tausend mal in 20 Sekunden ausführt.

Zitat von Glados:

Aber synchronisiert Queue nicht auch irgendwo wieder das Hauptformular komplett?

Was meinst du damit? Natürlich wird die Queue-Proc im Hauptthread aufgerufen, genau wie auch bei Synchronize. Der Unterschied ist, daß Synchronize wartet bis dies geschehen ist und Queue eben nicht.

Zitat von Glados:

Es ist besser lesbar und dafür gibt es 100 Punkte mehr als für PostMessage. Aber PostMessage, muss man leider sagen, ist wesentlich performanter wenn man das mehrere Tausend mal in 20 Sekunden ausführt.

Das mit der Performance kann ich ohne konkreten Anwendungsfall nicht beurteilen. Der Ablauf mit Queue ist aber im Prinzip folgender:

Die auszuführende Prozedur wird per Queue in eine Liste geschrieben. Dann wird der Hauptthread aufgeweckt indem ihm per PostMessage (sieh mal an!) ein WM_NULL geschickt wird. In der Application.WndProc wird diese Message dann mit einem CheckSynchronize verarbeitet. Das CheckSynchronize arbeitet dann alle aktuell in der Liste stehenden Queue-Procs ab. Gegenüber einer reinen PostMessage-Lösung könnte sich hier eigentlich nur die Verwaltung der Liste auf die Performance auswirken.

Zitat von Glados:

Es ist besser lesbar und dafür gibt es 100 Punkte mehr als für PostMessage. Aber PostMessage, muss man leider sagen, ist wesentlich performanter wenn man das mehrere Tausend mal in 20 Sekunden ausführt.

Wir haben zufällig vor einiger Zeit eine alte Message-basierte Lösung auf TThread.Queue umgestellt.
Der Quelltext ist dadurch sehr viel kürzer und übersichtlicher geworden und wurde von der Performance her tendentiell eher etwas schneller. Einen großen eindeutig messbaren Unterschied gab es jedenfalls nicht und damit gewinnt der bessere Code.

Zitat:

Das mit der Performance kann ich ohne konkreten Anwendungsfall nicht beurteilen.

Beispiel 1: gegeben ist ein Thread welcher sich alle 25ms die Position einer ProgressBar holt.
Beispiel 2: gegeben ist ein Thread der alle 25ms die Position einer ProgressBar setzt.

Gerade bei Beispiel 2 konnte ich große Unterschiede bzgl eines ruckelfreien Hauptformulars feststellen.

Beispiel 3: der Thread ist schlau genug und muß das nicht alle 25ms tun

Mein Thread ist schlau genug er prüft vorher, ob sich die ProgressBar überhaupt bewegt hat ob es überhaupt etwas zu ändern gibt, indem ein paar Daten abgeglichen werden.

Zusätzlich habe noch so etwas drin

markieren

Delphi-Quellcode:

if (System.DateUtils.MilliSecondsBetween(Now, iCurrentTime) >= 500) then
 begin
  // hier jetzt prüfen, ob ProgressBar überhaupt gesetzt werden muss
  
  iCurrentTime := Now;
 end;

Ich komme jedenfalls gut klar mit den PostMessages. Ich finde es nun sauberer und perfomanter.