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

[Glados]

Vor einiger Zeit war es noch OK, dass ich mit PostMessage Daten aus einem Thread an WndProc geschickt habe. Funktioniert wunderbare und ich bin Synchronize() losgeworden.

Ich stelle mir jetzt aber ein paar Kernfragen:
Synchronize aus einem Thread heraus Sychronisiert mit dem Hauptthread. Grob gesagt kann ich dann den zweiten Thread auch komplett weglassen wenn doch eh synchronisiert wird.

Wie sieht das aus, wenn man PostMessage verwendet und die Daten in WndProc (andere Unit) auswertet und dort die GUI aktualisiert.
Wird dann auch mit dem Hauptthread synchronisiert bzw. IST DAS überhaupt besser? Synchronize ist weg, das war mein Ziel.

Ich möchte nun gerne auch Zeichen ketten schicken können.
Dafür würde ich bei PostMessage bleiben, aber WndProc durch WMCopyData(var msg: TWMCopyData); austauschen, sodass ich Records schicken kann und flexibler bin.
Hat das gravierende Nachteile? Wenn ja, wie sonst Daten aus einem Thread heraus schicken, sodass man die GUI aktualisieren kann ohne Synchronize verwenden zu müssen?

[EWeiss]

Zitat:

aber WndProc durch WMCopyData(var msg: TWMCopyData); austauschen

Aha wie geht das?

gruss

[Glados]

Ich weiß nicht ob deine Frage ernst gemeint ist.
Wenn nicht und es Ironie ist, ignoriere ich sie einfach mehr oder weniger gekonnt.

[EWeiss]

Zitat:

Zitat von Glados (Beitrag 1384995)

Ich weiß nicht ob deine Frage ernst gemeint ist.
Wenn nicht und es Ironie ist, ignoriere ich sie einfach mehr oder weniger gekonnt.

Kannst du gerne tun.
Ja sie ist ernst gemeint.

WM_COPYDATA:
WM_COPYDATA ist ein Message die in der Winproc ausgewertet wird aber du möchtest die WinProc entfernen bzw. damit austauschen?
Wie geht das.

gruss

[Glados]

Wie wärs denn so? Ich kapiere noch immer nicht wieso du diese Frage gerade stellst.

Delphi-Quellcode:

type
 TPostMessageData = record
  sString: string;
  sInt: Integer;
 end;
 PPostMessageData = ^TPostMessageData;

Button1Click(Sender: TObject);
var
 CopyData: TPostMessageData;
begin
 CopyData.sString := 'String test';
 CopyData.sInt := 99;

 SendMessage(Handle, WM_COPYDATA, 0, Integer(@CopyData));
end;

procedure TFormReceiver.WMCopyData(var msg: TWMCopyData);
begin
 ShowMessage(PPostMessageData(msg.CopyDataStruct).sString);
end;

So kann ich senden was ich will. Nur frage ich mich: besser das unflexible WndProc-Event nutzen oder das deutlich flexiblere WMCopyData (ersteres mit PostMessage, letzteres mit SendMessage).
Aus einem Thread heraus.

Wenn ich das richtig verstanden habe, blockiert SendMessage den Thread erst einmal. Auch wenn es nicht lange ist. PostMessage, da asynchron, macht das wohl nicht.

[EWeiss]

Zitat:

Zitat von Glados (Beitrag 1385001)

Wie wärs denn so? Ich kapiere noch immer nicht wieso du diese Frage gerade stellst.

Delphi-Quellcode:

type
 TPostMessageData = record
  sString: string;
  sInt: Integer;
 end;
 PPostMessageData = ^TPostMessageData;

Button1Click(Sender: TObject);
var
 CopyData: TPostMessageData;
begin
 CopyData.sString := 'String test';
 CopyData.sInt := 99;

 SendMessage(Handle, WM_COPYDATA, 0, Integer(@CopyData));
end;

procedure TFormReceiver.WMCopyData(var msg: TWMCopyData);
begin
 ShowMessage(PPostMessageData(msg.CopyDataStruct).sString);
end;

Du hast geschrieben das du die Winproc ersetzen\austauschen willst.
Das ist schlicht weg falsch und nicht möglich.

Du kannst deine eigene Message Queue aus dieser ableiten aber die Winproc austauschen vergiss es.
Lese doch einfach mal was du geschrieben hast.

Zitat:

blockiert SendMessage den Thread erst einmal.

Nö.
Sendmessage wartet auf die Rückgabe PostMessage eben nicht!

Bin raus!

gruss

[Glados]

Zitat:

Sendmessage wartet auf die Rückgabe PostMessage eben nicht!

SendMessage wartet auf die Rückgabe, also wird blockiert oder bin ich jetzt neben der Spur?
Ich muss auf keine Rückgabe warten. Ich möchte einfach nur die GUI aus einem Thread heraus aktualisieren ohne Synchronize verwenden zu müssen :P

WndProc zusammen mit Record und PostMessage:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
 CopyData: PPostMessageData;
begin
 CopyData := New(PPostMessageData);
 CopyData.sString := 'String test';
 CopyData.sInt := 99;

 PostMessage(Handle, 50, 0, Integer(CopyData));
end;

procedure TForm1.WndProc(var msg: TMessage);
begin
 case msg.msg of
  50:
   begin
    ShowMessage('WndProc: ' + PPostMessageData(msg.LParam)^.sString);
   end;
 end;

 inherited;
end;

Was ist denn davon zu halten einen ganzen Record zu übergeben und immer mit New einen anzulegen?

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1384979)

Vor einiger Zeit war es noch OK, dass ich mit PostMessage Daten aus einem Thread an WndProc geschickt habe. Funktioniert wunderbare und ich bin Synchronize() losgeworden.

Hatte das

Delphi-Quellcode:

Synchronize

irgendwelche Probleme bereitet, oder warum wolltest du das loswerden?

Zitat:

Zitat von Glados (Beitrag 1384979)

Synchronize aus einem Thread heraus Sychronisiert mit dem Hauptthread. Grob gesagt kann ich dann den zweiten Thread auch komplett weglassen wenn doch eh synchronisiert wird.

Du synchronisierst ja nicht alle Aktionen des 2. Threads, sondern nur exakt die Stellen, die auf die VCL/GUI zugreifen. Alle anderen Berechnungen laufen dann ja trotzdem parallel ab.

Zitat:

Zitat von Glados (Beitrag 1384979)

Wie sieht das aus, wenn man PostMessage verwendet und die Daten in WndProc (andere Unit) auswertet und dort die GUI aktualisiert.
Wird dann auch mit dem Hauptthread synchronisiert bzw. IST DAS überhaupt besser? Synchronize ist weg, das war mein Ziel.

Die MessageQueue läuft auch im Hauptthread. Bei Verwendung von PostMessage, würde ich das Verhalten allerdings eher mit

Delphi-Quellcode:

TThread.Queue

vergleichen (hierbei läuft der aufrufende Thread auch weiter; anders als beim

Delphi-Quellcode:

TThread.Synchronize

).

[Glados]

Zitat:

Hatte das Synchronize irgendwelche Probleme bereitet, oder warum wolltest du das loswerden?

Irgendwann hat man es schon gemerkt und die Anwendung wurde tatsächlich träge.
Nachdem ich sehr viel in WndProc ausgelagert habe und PostMessage verwende, ist der Unterschied deutlich spürbar.

Zitat:

Die MessageQueue läuft auch im Hauptthread. Bei Verwendung von MSDN-Library durchsuchenPostMessage, würde ich das Verhalten allerdings eher mit TThread.Queue vergleichen (hierbei läuft der aufrufende Thread auch weiter; anders als beim TThread.Synchronize ).

ist es demnach korrekt-er WndProc (oder was anderes) zu verwenden statt Synchronize;

Mein Ziel ist es, alle Synchronize und Queue aus den Threads zu bekommen.

Daher habe ich mir das da oben mal zusammengestrickt. Record > PostMessage > WndProc. Frage ist nur, ob das in Ordnung ist?

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1385011)

Zitat:

Die MessageQueue läuft auch im Hauptthread. Bei Verwendung von MSDN-Library durchsuchenPostMessage, würde ich das Verhalten allerdings eher mit TThread.Queue vergleichen (hierbei läuft der aufrufende Thread auch weiter; anders als beim TThread.Synchronize ).

ist es demnach korrekt-er WndProc (oder was anderes) zu verwenden statt Synchronize;

Mein Ziel ist es, alle Synchronize und Queue aus den Threads zu bekommen.

Daher habe ich mir das da oben mal zusammengestrickt. Record > PostMessage > WndProc. Frage ist nur, ob das in Ordnung ist?

Bei vielen deiner Fragen denke ich an klassisches "Overengineering" :stupid:

WndProc und PostMessage ist der native WinAPI Weg für solche Dinge. Delphi ist nunmal eine höhere Programmiersprache, welche einige Abstraktionen bereitstellt. Ich kann dir hier nur meine persönliche Meinung sagen, aber ich würde in 99% aller Fälle bei

Delphi-Quellcode:

TThread.Synchronize

bzw.

Delphi-Quellcode:

TThread.Queue

bleiben. Probier es mal mit Letzterem und beachte zusätzlich, dass du wirklich nur die erforderlichen Codestellen synchronisierst. Auch hilfreich kann sein, die GUI Aktualisierung nicht nach jedem Rechenschritt auszuführen. Wenn du z.b. eh nur eine ProgressBar updatest, kannst du das ja ggfls. auch ohne Probleme nur alle 1000 Iterationen oder so durchführen, ohne dass man als Mensch davon etwas mitbekommt.

In Ordnung ist deine Methode vermutlich auch, bloß machst du es dir dadurch unnötig schwer und reduzierst zudem wahrscheinlich auch die Lesbarkeit deines Codes.

[Glados]

Zitat:

Bei vielen deiner Fragen denke ich an klassisches "Overengineering"

Ich versuche nur das umzusetzen, was hier immer angepriesen wird: GUI nicht aus einem Thread heraus aktualisieren :stupid:

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1385015)

Zitat:

Bei vielen deiner Fragen denke ich an klassisches "Overengineering"

Ich versuche nur das umzusetzen, was hier immer angepriesen wird: GUI nicht aus einem Thread heraus aktualisieren :stupid:

Das ist auch definitiv gut :thumb: Ich bezog mich eher darauf, dass du manchmal recht geschickt bist, die Delphi eigenen Funktionen durch Eigenentwicklungen ersetzen zu wollen :-D

[Glados]

Geschickt würde ich nicht sagen. Ich setze einfach 08 und 15 zusammen und erhalte 0815-Lösungen.

Was könnt ihr Profis denn abschließend dazu sagen: Queue oder WndProc mit PostMessage und Record.
Es geht hier um Threads die einiges zu tun haben und die GUI recht häufig und schnell hintereinander aktualisieren, da es um Live-Daten geht wenn man das so nennen kann.

[Edelfix]

Währe TThreadedQueue eventuell ein Weg?
Mit einem extra Thread der die GUI aktualisiert und der pull das Queue leert. So können mehreren Threads die das Queue per push voll machen ohne zu blockieren.

[Glados]

Von TThreadedQueue höre ich zum ersten mal.

Wie würde denn dann aus diesem Extra-Thread heraus aktualisiert. Auch wieder mit Synchronize?

[Edelfix]

Ja mit Synchronize.

Ich habe kein Beispiel und habe damit bis jetzt nur eine Log Funktion umgesetzt aber die Idee fand ich gut.

Wenn ich das richtig verstanden hatte dann funktioniert die TThreadedQueue wie eine Art Spender (z.B. Rollen Spender).
Oben wird nachgefüllt und unten nach und nach leer gemacht.

Ist im Grunde wie ein Puffer der den Job Threads die Warte Zeit abnimmt.

[Glados]

Nur dann wäre ich ja wieder beim Synchronize, wovon ich eigentlich weg möchte.

[Bernhard Geyer]

Ich habe jetzt nicht gesehen ob es schon angesprochen wurde:
WM_COPYDATA muss mit SendMessage verwendet werden und WM_COPYDATA hat bei uns (früher) nicht als Kommunikation im Prozess funktioniert (nur zwischen Prozessen).

[Glados]

Zitat:

WM_COPYDATA muss mit SendMessage verwendet werden und WM_COPYDATA hat bei uns (früher) nicht als Kommunikation im Prozess funktioniert (nur zwischen Prozessen).

Funktioniert bei mir wie gewünscht im selben Prozess.
Ich glaube ich bleibe aber bei WndProc. Ob ich ein ganzes Record schicke muss ich noch gucken. Eventuell schicke ich Strings sogar nur so

Delphi-Quellcode:

PostMessage(receiver, command, wParam, Integer(PChar(string)));

[HolgerX]

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

Ich habe dies benutzt, um Texte aus Threads heraus an den MainThread zu schicken ohne Verwendung von Synchronize...

[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.

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1385323)

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.

Sind ja nur nett gemeinte Hinweise. Ich bin nebenbei erwähnt auch TiGüs Meinung, dass deine Performanceprobleme eine andere Ursache haben (falsche Verwendung von

Delphi-Quellcode:

Tthread.Queue

). Falls du das komplette Projekt hochladen kannst/willst, würde ich sogar mal drüberschauen. Gerne auch per PN.

[Zacherl]

Habe das jetzt nochmal getestet mit einem Thread, der exakt 1 Sekunde lang einen Wert in einer Schleife inkrementiert.

Bild 1 zeigt den endgültigen Wert der Variable nach Beendigung des Thread.
Bild 2 führt nebenher den gleichen Task auch nochmal im Main Thread aus.

Wie man sieht es lediglich

Delphi-Quellcode:

TThread.Synchronize

von der Performance her minimal schlechter.

Delphi-Quellcode:

TThread.Queue

ist genauso schnell wie SendMessage oder PostMessage.

Synchronisiert wird jeweils wenn

Delphi-Quellcode:

Value mod 100000 = 0

, also jeweils nach 100.000 Iterationen.

[Glados]

Muss ich Queue aus dem Thread heraus aufrufen oder kann ich im Thread eine Prozedur in einer anderen Unit aufrufen und von dort aus Queue?
Wenn letzteres möglich ist, könnte ich Queue und PostMessage direkt gegenüberstellen und mit nur einer einzigen geänderten Zeile testen.

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1385421)

Muss ich Queue aus dem Thread heraus aufrufen oder kann ich im Thread eine Prozedur in einer anderen Unit aufrufen und von dort aus Queue?

Ja. Die Funktion muss allerdings die Instanz des Threads übergeben bekommen. Alternativ kannst du auch ohne Instanz folgendes machen

Delphi-Quellcode:

TThread.Queue(TThread.Current, ...)

. Der Aufruf von

Delphi-Quellcode:

TThread.Current

könnte deinen Test allerdings verfälschen.

[Glados]

Ich bastel erstmal das Grundgerüst zusammen und gucke was sich dann anbietet.

[Zacherl]

Habe mein Testprojekt mal aufgeräumt und angehangen. Ist sicherlich keine ganz perfekte Messung, aber egal was ich probiere:

Delphi-Quellcode:

TThread.Queue

ist gleich schnell wie

Delphi-Quellcode:

PostMessage

und

Delphi-Quellcode:

TThread.Synchronize

gleich schnell wie

Delphi-Quellcode:

SendMessage

.

[Glados]

Dann bleibe ich der Einfachheit halber bei PostMessage. Das ist alles schon implementiert und kann nur besser gemacht werden.
Alles zu Queue umzuändern würde wieder alles über den Haufen werfen.