Danke euch für die guten Vorschläge!
NytroX hat geschrieben: ↑21.06.2023, 20:02
Gibt es einen Grund, warum du sie nicht einfach abholen und in eine eigene Queue schreiben kannst? Dann kannst du beim Durchlauf zählen.
Ansonsten könntest du sie ja auch abholen und mit "SendMessage" quasi wieder "oben reinstecken". Aber das ist ein böser Hack :-)
Ich denke du meinst
PostMessage (?). Mit
SendMessage laden die Nachrichten ja nicht in der Message Queque sondern werden direkt an die Callback function weitergereicht.
Die Idee wäre ja an sich nicht schlecht, doch Nachrichten des Typs WM_PAINT kriegt man ja weder mit GetMessage noch mit PeekMessage einfach abgeräumt. Nur wenn der Bereich als "aktualisiert" gekennzeichnet wird, entfernt Windows WM_PAINT (also entweder über ValidateRect, ValidateRgn oder BeginPaint / EndPaint). Alternativ überlässt man die Nachricht DefWindowProc. (Petzold S. 196, 197, deutsche Ausgabe).
Eigentlich würde ich die Nachrichten alle gerne in der Message Queque belassen. Aber da man ja anscheinend keine Möglichkeit hat, zu erkennen, ob man ein und dieselbe Nachricht wieder "in den Händen" hält, sehe ich auch keine Lösung, die Nachrichten in der Schlage auf diese Weise zu zählen. Sonst könnte man ja einfach alle Nachrichten unbearbeitet durchgehen, bis man wieder zur selben Nachricht gelangt.
gombolo hat geschrieben: ↑21.06.2023, 20:19
http://winapi.freetechsecrets.com/win32 ... Status.htm
hmmm->The high-order word of the return value indicates the types of messages currently in the queue. The low-order word indicates the types of messages that have been added to the queue and that are still in the queue since the last call to the GetQueueStatus, GetMessage, or PeekMessage function.
unter Umständen damit?
Danke, damit hatte ich es auch schon versucht. Bei mir kam aber leider nie die konkrete Anzahl der Nachrichten als Rückgabewert.
Wenn ich die Funktion richtig verstehe, liefert sie blos die Anzahl der Nachrichten-Typen. So 100% schlau bin ich daraus noch nicht geworden:
The high-order word of the return value indicates the types of messages currently in the queue. The low-order word indicates the types of messages that have been added to the queue and that are still in the queue since the last call to the GetQueueStatus, GetMessage, or PeekMessage function.
Krishty hat geschrieben: ↑21.06.2023, 20:41
Viele Win32-Nachrichten sind keine echten Nachrichten, die in der Schlange landen.
WM_MOUSEMOVE,
WM_TIMER und
WM_PAINT sind sowas – wenn die Anwendung viel zu tun hat, werden sie erst gar nicht generiert; wenn die Anwendung leer läuft, ständig.
Davon ab hast du aber doch sicher irgendwo
GetMessage() oder
PeekMessage() laufen, wie gombolo sagt?
Wenn du den Zähler nicht direkt in der Anwendung brauchst, sondern nur mal gucken willst, gibt Spy++ dir auch alle Nachrichten zu einem Prozess aus.
Ich habe beides versucht - mittels GetMessage und über PeekMessage. Aber auf eine Lösung bin ich nicht gekommen.
Soviel ich jetzt verstanden habe, gibt es indirekte Nachrichten und direkte Nachrichten. Nur die Indirekten laden dabei in der Message Queque.
Z. B.
sendet UpdateWindow eine WM_PAINT Nachricht direkt an die registrierte Callback Funktion.
Deine Aussage bezieht sich aber nicht darauf, oder?
Wenn das so ist, dann wird das Ganze ja ziemlich schnell "undurchschaubar". Wird das später nicht zum Problem, wenn man sich nicht darauf verlassen kann, ob z. B. eine WM_TIMER Nachricht nun gepostet wird - oder nicht gepostet wird?
Also ist möglicherweise meine Idee so nicht umsetzbar...
Gewisse Dinge hätten sich so quasi sehr einfach experimentell feststellen lassen.
Z. B. bin ich mir nicht ganz sicher, ob sich tatsächlich nur maximal eine WM_PAINT Nachricht in der Schlange befinden kann (egal zu welcher Zeit). Sowas (und Anderes) könnte man sofort sehen, wenn man die Anzahl der Nachrichten auslesen könnte.