Zitat von Glados:

Liegt das vielleicht an meinem Code?
Pseudo!

Wie wäre es, wenn du dem Thread eine anonyme Methode übergibst und darin den Code ausführst, der nach der Abarbeitung der Threadaktionen laufen soll. Dann sparst du dir das ganze Warten usw.

Ich weiß jetzt nicht genau wie das funktionieren soll, da ich einerseits in Button1Click am Ende etwas ausführe aber auch schon vorher nach der While-Schleife in UnitX.Prozedur1.
Einfach 2x das was du sagtest?

Zitat:

Was glaubst Du verbirgt sich hinter handle of destination window?

Ich betone es noch einmal. Ich habe nur diesen Code hier abgeguckt mehr nicht https://www.entwickler-ecke.de/topic..._106970,0.html
Von mehr habe ich auch keine Ahnung.

Zitat:

und dort wird die Message verarbeitet, und sei es durch ignorieren....

ich habe keine Ahnung wo dort sein soll.


Es funktioniert jetzt. Ich habe vorher laut Entwickler-Ecke das Handle der Progressbar übergeben.

Ich habe jetzt soweit alle Synchronize und TTHread.Queue entfernt und durch PostMessage ersetzt.
Um das alles ordentlich handeln zu können habe ich ein paar const angelegt, die ich den PostMessage übergebe und dann in WndProc mit einem Case auswerte.
Das Case hat 7 Blöcke.

Ist das schon besser als für alles ein Synchronize zu verwenden? Die Bedienung der GUI fühlt sich, wenn Threads laufen und PostMessage's abschicken statt Synchronize ausführen, jetzt in jedem Fall wesentlich "flüssiger" an. Man merkt gar nicht mehr, dass im Hintergrund etwas arbeitet.

Meine Konstanten sind aber noch fragwürdig.

markieren

Delphi-Quellcode:

... = WM_USER + 1;
... = WM_USER + 2;
... = WM_USER + 3;

Geht das nicht besser als mit WM_USER + N; ?

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.