lokaler Hook wird immer doppelt durchlaufen?

[r29d43]

Zitat von Uwe Raabe:

Hast du schon mal einen Haltepunkt gesetzt und den Aufruf-Stack angeschaut?

Thx für den Tipp, der brachte was. Denn da sah ich auf einmal, wie bei den einzelnen Hookbesuchen ständig zwischen 0 und 1 wechselnde Werte im wParameter-Parameter auftauchten. Gemäß der MSDK beinhaltet dieser wParameter die Information darüber, ob die Message schon von der Message-Schlange entfernt wurde oder ob nicht. (Das hatte ich bisher einfach als eher unwichtig ignoriert).

Demgemäß scheint es also doch normal zu sein, dass zumindest eine GetMsgProc bei jeder Message zweimal aufgerufen wird. Nämlich einmal mit der Message wo diese noch nicht von der Message-Schlange heruntergenommen wurde, und ein zweites Mal wo das schon geschehen ist und wo diese Message dann anschließend (nach der Hook-Kette) direkt zur WndProc des Control weitergeschickt werden wird.

Soll heißen (zumindest für mich): Wenn man auf eine Message in so einer GetMsgProc reagieren möchte, dann muss man also auch diesen wParameter noch mit berücksichtigen und kann so auch nochmal ein bisschen genauer auf die Situation reagieren ...schon bei einer angänglichen Vorab-Betrachtung der Message, bevor die überhaupt schon abgeschickt wurde, oder erst danach wenn fest steht, dass sie tatsächlich zum Control abgeschickt wurde etc. etc..

Zacherl lag also doch schon irgendwo richtig mit seiner Vermutung

Zitat:

Ich vermute mal, dass die VCL da intern irgendwie mit den Messages hantiert und dadurch verursacht, dass diese manchmal doppelt verschickt werden.

nur anstatt "manchmal" eben wahrscheinlich immer (im oben erwähnten Kontext).

[r29d43]

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 )