Schrompf hat geschrieben:Und dazu ein Fenster mit einer MsgProc, in der man nochmal auf ne subtil andere Art Messages behandelt. Nun war ich der Meinung, dass die beiden gleichwertig sein sollten. Ich müsste also alle Nachrichten auch in der while()-Schleife behandeln können. Aber Pustekuchen. Seit ich das Fenster nicht mehr selbst erstelle und demzufolge die MsgProc in anderen Händen liegt, kriege ich z.B. Alt+F4 nicht mehr mit. Oder einen Klick auf den Schließen-Button des Fensters.
Was verwendest du denn für Parameter für das PeekMessage? Einen konkreten Window-Handle oder lässt du dir die Nachrichten aller Fenster im aktuellen Thread liefern (hwnd = NULL)? Vielleicht kommen Alt+F4 bzw. WM_CLOSE direkt als Non-Window-Event oder für ein anderes Window-Handle. Den Nachrichtenfilter wirst du wahrscheinlich nicht einschränken.
Schrompf hat geschrieben:Daher allgemein: wie hängen diese beiden Nachrichtenbehandler zusammen? Anscheinend kommen ja bestimmte Sachen direkt über den Callback rein und gehen an der PeekMessage()-Schleife vorbei. Und was bewirkt das Dispatch() am Ende? Ich dachte, das reicht die Nachrichten an den Callback weiter, aber woher soll es den kennen? Und was passiert, wenn keiner gesetzt ist?
Die MSG-Struktur, die von PeekMessage befüllt wird, enthält den Window-Handle und den übergibst du mit an DispatchMessage. Er kennt also das Ziel-Fenster und somit auch die MsgProc, die damit assoziiert ist oder ggf. DefWindowProc.
Nachtrag: WM_QUIT scheint man nur zu bekommen, wenn man beim PeekMessage oder GetMessage einen Window-Handle von NULL verwendet. WM_CLOSE und WM_DESTROY (und einige andere) hingegen, scheinen tatsächlich nur in der Fenster-Prozedur abrufbar zu sein. Warum auch immer.
Hier ein Zitat aus StackOverflow:
It seems that WM_CLOSE is sent, and the other message is posted.
GetMessage and PeekMessage only operate on posted messages (those posted with PostMessage). If a message is not posted but sent via SendMessage, it's handled immediately inside PeekMessage or GetMessage, so you can not get MSG struct for it.
Macht irgendwie auch Sinn, weil SendMessage ja blockiert, bis die Abarbeitung beendet ist, während PostMessage das Teil einfach in die Queue packt für eine spätere Abarbeitung.
Du könntest aber ein bisschen tricksen. #undef auf SendMessage, dann ein Zeichensatz-spezifisches Re-define, welches WM_CLOSE usw. verarbeitet und dann an SendMessageA bzw. SendMessageW weiterleitet bzw. im Fall von WM_CLOSE zusätzlich ein PostMessageA bzw. PostMessageW. ;)
Ohne Input kein Output.