Vielleicht noch eine kleine Ergänzung dazu:
Diese pro einer Message doppelten Hook-Aufrufe gibts auch noch bei einigen anderen lokalen Hooks. Zum Beispiel auch beim lokalen Mouse-Hook (den ich bisher immer nutzte). Bei diesem war mir nur bisher noch nicht aufgefallen, weil der von mir irgendwoher kopierte Code zur Message-Bearbeitung mit <
if nCode = HAction then> begann (und im MouseHook das Info, ob die Message schon von der MsgLoop gelöscht wurde, schon im 'nCode'-Parameter sitzt). Das nämlich lässt den Hook-Durchlauf mit noch nicht von der Message-Loop gelöschten Message außen vor. Den würde man bekommen mit <
if nCode = HC_NOREMOVE then>. Und wenn man die Message-Bearbeitung im Mouse-Hook mit <
if nCode >= 0 then> beginnt, dann bearbeitet man auch beim Mouse-Hook tatsächlich beide Hook-Durchläufe pro Message. Auch beim Keyboard-Hook (WH_KEYBOARD) dürfte das so ganz ähnlich liegen.
Ob es so einen doppelten Hookdurchlauf pro Message überhaupt gibt hängt davon ab, ob beim Auslesen der Message die
Api-Funktionen GetMessage oder PeekMessage beteiligt sind (dann wird der Hook vom System aufgerufen) und ob die Application zum Abgreifen dieser Message von der MsgLoop dafür z.B. 2 PeekMessage-Calls benutzt. Einen ohne die Message dabei zu löschen, und einen zweiten mit Message-Löschung und anschließend dann wohl Weiterleitung an die WndProc des jeweiligen Controls (...so +/- gemäß MSDK).
Last but not least: Wer oben event. mitgelesen hat weiß, dass es mir hier letztlich um die
wm_move und
wm_moving -Messages ging. Messages, die man jetzt aber zufälligerweise garnicht durch einen GetMsg-Hook bekommt, sondern wofür man einen lokalen
CallWnd-Hook (WH_CALLWNDPROC) benötigt.
(Das nur der Vollständigkeit halber, weil's bei vielen sicher ähnlich liegt wie bei mir: Einen 'perfekten' schönen Code aus dem Internet kopiert und deswegen an dieser Sache nie vorbeigekommen
)