PostMessage mit WndProc oder WMCopyData/Record aus Thread für GUI-Aktualisierung?

[Glados]

Zitat:

ohne Verwendung von Synchronize...

Genau aus demselben Grund versuche ich diese komischen Umwege ja auch :P

[Bernhard Geyer]

Zitat:

Zitat von HolgerX (Beitrag 1385054)

Hmm..

das mit WM_COPYDATA kann im selben Process nur funktionieren, wenn zwischen verschiedenen Threads..

Denn die Message kann im selben Thread nicht abgearbeitet werden, da diese ja noch auf das Return vom SendMessage wartet ;)

Es war kein Problem das es überhaupt nicht funktioniert hat sondern hin und wieder einfach nicht angekommen ist.

[Zacherl]

Also WM_COPYDATA ist eigentlich eh nur für IPC gedacht. Wenn man damit eh gezwungenermaßen SendMessage verwenden muss, dann kannst du genausogut eine eigene Message definieren und einfach lParam oder wParam auf deinen Record zeigen lassen. Hier hast du aber dann das exakt gleiche Verhalten wie bei

Delphi-Quellcode:

TThread.Synchronize

, sprich: Der aufrufende Thread wird solange blockiert, bis das Mainthread die Nachricht abgearbeitet hat.

[Glados]

Außer ich nutze PostMessage. Das entspricht dann ja, wie du sagtest, etwa Queue.

Was ist denn dann die richtige Methode um die GUI aus einem Thread zu aktualisieren?

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1385071)

Außer ich nutze PostMessage. Das entspricht dann ja, wie du sagtest, etwa Queue.

So wie ich Bernhard verstanden habe, erfordert WM_COPYDATA zwangsweise SendMessage.

Zitat:

Zitat von Glados (Beitrag 1385071)

Was ist denn dann die richtige Methode um die GUI aus einem Thread zu aktualisieren?

Wie gesagt: Nimm einfach

Delphi-Quellcode:

TThread.Queue

:)

[Glados]

Nee Synchronize und Queue hab ich doch erst kürzlich fast völlig ausgemerzt und einen guten Performancevorteil spürbar gemacht :P

[EWeiss]

Er könnte es ja eventuell auch mal mit PostThreadMessage versuchen.
Aber ich glaube das ist genauso wenig möglich wie mit PostMessage.

laut MSDN wird davon abgeraten etwas anderes als SendMessage zu verwenden.

gruss

[Glados]

Zitat:

laut MSDN wird davon abgeraten etwas anderes als SendMessage zu verwenden.

Ich habe irgendwo mal gelesen man soll Send bzw Synchronize verwenden wenn man die dadurch erhaltenen Daten danach sofort braucht. Ansonsten kann man Post/Queue verwenden.
Wo ich das gelesen habe weiß ich nicht mehr.

[TiGü]

Zitat:

Zitat von Glados (Beitrag 1385074)

Nee Synchronize und Queue hab ich doch erst kürzlich fast völlig ausgemerzt und einen guten Performancevorteil spürbar gemacht :P

Nimm einfach TThread.Queue.
Deine Performanceprobleme haben höchstwahrscheinlich andere Ursachen.

Beliebter Anfängerfehler ist zum Beispiel der Versuch den Fortschritt einer Dateioperation (aus dem Internet downloaden oder Datei kopieren) im Mainthread per Progressbar sichtbar zu machen.
Dabei wird jedes Datenpaket und/oder schlimmer noch jedes einzelne neue Byte an den Mainthread signalisiert, anstatt die prozentuale Änderung im Thread zu berechnen und damit maximal ca. 100 mal den Mainthread signalisieren zu müssen.
Günstiger wären auch größere Schrittweiten möglich (5 oder 10 %).

[Glados]

Zitat:

Nimm einfach TThread.Queue.
Deine Performanceprobleme haben höchstwahrscheinlich andere Ursachen.

Ich will mich jetzt nicht selber zitieren. Aber ich habe Queue rausgenommen eben WEIL es Probleme verursacht hat.
Mit PostMessage sind die Probleme weg.

Wieso wiederholt ihr dann immer wieder denselben Quark :roll:

Ist mit jedenfalls ab sofort egal. Bin raus hier.