Hm, das was du versucht's kann nicht funktionieren.
Ich versuche dich mal mit einer Gegenfrage auf die Denk-fährte zu bringen.
Die zwei letzten Paramter von SetWindowHookEx() sind entweder eine ThreadID oder ein Instancehandle eines geladenen Modules (nur eines darf angegeben werden, eines muß 0 sein).
Nun WARUM und WOFÜR könnte Windows diese beiden Werte benötigen ??
Angenomen die ThreadID lässt sich ebenfalls im Kernel
API auf ein Instance-
handle eines geladenen Modules reduzieren, dies ist fakt. Und wenn nun ein Instance-
Handle aus der Sicht des Windows Kernels nichts anderes ist als ein Zeiger in den Speicher einen Modules ?
Windows benötigt also in jedem Falle eines Zeiger auf den Speicher zu einem geladenen Modul. Warum ?
Weil exakt dort die Callback Funktion liegen sollte. Du kannst nicht aus deinem Modul heraus einen Hook erzeugen auf ein anderes Modul referneziert.
Denn in deiner Callback rufst du CallNextHookEx(HookHandle, ...) auf. Aber WO wurde die Variable HookHandle denn gespeichert ? Natürlich in Datensegement deines Prozesse, eg Modules. Die Hook-Callback wird aber im Context des angegeben Ziel-Prozesses aufgerufen der garnicht auf DEIN Datensegment zugreifen kann. D.h. mit CallNextHookEx(HookHandle, ...) erzeugt der Compielr Code um auf HookHandle im Datensegement zuzugreifen. Dies Speicherbereich steht aber im Zielprozess nicht zur Verfügung oder enthält falsche Daten.
In deinem Falle must du eine
DLL programmieren. In dieser
DLL installierst du einen lokalen Mouse Hook. Diese
DLL wird durch einen Globalen Hook in alle Prozesse injeziert zb. mit WH_CALLWNDPROC o.ä. Innerhalb der
DLL installierst du NUR für den gültigen Zielprozess den lokalen Mousehook und rufts LoadLibrary(HInstance,,) auf. Danach deinstallierst du den globale Hook.
Eine andere Möglichkeit mit Code-Injects habe ich dir hier im Forum schon aufgezeigt.
Gruß Hagen