Dringende Nachrichtenbehandlung vor block. Fkt. ausführen
-
Hallo Leute,
hoffe ich finde hier eine Lösung meiner Herausforderung.Ich versende mit SendMessage() eine selbst gebaute Nachricht, welche einen Text in ein bestimmtes Mehrzeiliges Editfield schreiben soll.
Direkt in der nächsten Zeile wird eine Anfrage an einen Server geschickt, und mein Programm wartet auf die Antwort vom Server.
Es wird durch eine EmpfangsFunktion blockiert, solange bis der Server sich zurückmeldet.
Der Text für das Editfield wird nicht angezeigt bevor der Server sich zurückmeldet, da ist es aber bereits zu spät. Die Nachricht müsste eigentlich abgearbeitet worden sein, ist ja SendMessage() und nicht PostMessage().
Anscheinend ist die Zeit zum ändern des Textes zu kurz, er springt vorher schon in die EmpfangsFunktion und diese blockiert halt alles.Hat jmd eine gute Idee oder bereits Erfahrung mit sowas gemacht ???
-
Die Nachricht wurde schon verarbeitet, allerdings hatte das Programm noch keine Zeit, das auf dem Bildschirm darzustellen (das macht er erst in der WM_PAINT-Verarbeitung - und die startet erst, wenn du nichts wichtigeres zu tun hast). Eventuell wäre es eine Lösung, die Server-Anfrage in einen extra Thread auszulagern, währnd das Hauptprogramm sich wieder um seine sonstigen Angelegenheiten kümmern kann.
-
Das Anzeigen von COntrols erfolgt asynchron und erst wenn die Nachrichtenschleife nichts mehrzu tun hat.
Wenn der Text als in das Control gesendet wurde (SetWindowText, ReplaceSel), dann kannst Du mit UpdateWindow ein Anzeigen sofort erzwingen!
-
Große Klasse, mit UpdateWindow() klappt das Wunderbar.
Und die WM_PAINT-Geschichte hat mich auf eine IDEE
gebracht:GetDlgItem(IDC_EDIT)->SetWindowText("hastenichgesehen"); GetDlgItem(IDC_EDIT)->SendMessage(WM_PAINT);Klappt auch wunderbar und es wird nur das eine ControlItem neu gemalt.
Mir ist nun klar, das WM_PAINT ebenfalls in die NachrichtenSchlange gepackt wird, dachte eine Änderung der Kontrollfelder hat automatisch höhere Priorität
und damit sofortige Ausführung zur Folge.Nun ist das WE doch noch gerettet.
Vielen Dank!!!
-
Daniellus schrieb:
Mir ist nun klar, das WM_PAINT ebenfalls in die NachrichtenSchlange gepackt wird, dachte eine Änderung der Kontrollfelder hat automatisch höhere Priorität
Ja, die Änderung wird sofort ausgeführt, aber das Darstellen steht in der Priorität ganz weit unten (und wird, wenn du es nicht selber anordnest, erst in der Idle-Verarbeitung erledigt).
-
Daniellus schrieb:
GetDlgItem(IDC_EDIT)->SetWindowText("hastenichgesehen"); GetDlgItem(IDC_EDIT)->SendMessage(WM_PAINT);Am Besten schmeißt Du das sofort wieder raus. WM_PAINT darf nicht selbst versendet werden! UpdateWindow und RedrawWindow sind die einzig korrekten Methoden einen Redraw zu erzwingen!
Nur weil solch eine Nachricht existiert kann man sie nicht einfach versenden! Gleiches gilt z.B: für WM_SETFOCUS/WM_KILLFOCUS und viele andere Nachrichten.
-
Hallo Martin,
könntest du mir bitte erklären warum man diese Nachricht nicht selber versenden darf?
-
WM_PAINT ist eine Systembedingte Nachricht die automatisch, die automatisch durch PeekMessage/GetMessage erzeugt wird. Diese Nachricht wird bedingt durch invalidierte Bereiche erzeugt wird.
Das Problem ist, dass Du mit den selbsterzeugten Nachrichten "die Automatik" gut durcheinander bringst.Aber das steht doch klar in der Doku gleich als erster Satz:
The WM_PAINT message is generated by the system and should not be sent by an application. To force a window to draw into a specific device context, use the WM_PRINT or WM_PRINTCLIENT message. Note that this requires the target window to support the WM_PRINTCLIENT message. Most common controls support the WM_PRINTCLIENT message.
-
Klar steht was in der Doku, aber nicht das es verboten ist.
Weil du meintest "man darf nicht".
Du hast da wohl was falsch übersetzt."should not" heißt man "sollte nicht"!
"must not" heißt man "darf nicht"!Halb so wild, ein bisschen English++ kann nicht schaden.
Werde diese Nachricht nun selbstverständlich nicht mehr selber verschicken, die denken sich schon was dabei!
Schönes Wochenende
-
"Must not" wirst Du in der MSDN kaum finden!
Nur mal so als Anmerkung.Ja meine Wortwahl war härter, aber oft genug werden hier im Forum Lösungsmöglichkeiten mit dem Versenden von Nachrichten angeboten, die man nicht versenden sollte, oder die Seiteneffekte auslösen, dass ich mich lieber etwas härter ausdrücke...
Und manchmal habe ich auch keine Lust zu diskutieren, wenn man "sollte" schreibt lädt das gerade zu ein eine Diskussion anzufangen!
