Wie kann ich verhindern, dass ein bestimmtes Fenster keine WM_MOUSEMOVE mehr bekommt?
-
-EDIT-
Wie kann ich verhindern, dass ein bestimmtes Fenster keine WM_MOUSEMOVE mehr bekommt?
Ich habe dazu etwas zu Hooks gefunden, aber mit ner Extra-DLL und alles überwachen. Das gefällt mir nicht.
Kann ich auch Hooks für ganz bestimmte Fenster "einhaken", damit nur die Nachrichten an dieses Fenster überwacht werden? Ohne eine DLL schreiben zu müssen?
-
Was?
-
Blaze schrieb:
Wie kann ich verhindern, dass ein bestimmtes Fenster keine WM_MOUSEMOVE mehr bekommt?
Das ist unnötig, weil Windows standardmäßig verhindert, daß ein Fenster keine WM_MOUSEMOVE bekommt.
-
Mist, doppelte Verneinung.
Ich meinte, wie kann ich ein Programm von sämtlichen WM_MOUSEMOVE Nachrichten abschnüren?
-
SetWindowsHookEx
-
Gut, soweit war ich auch schon. Könntest du mir bitte mal erklären, wie ich WH_GETMESSAGE eines bestimmten Fensters hooken kann, ohne gleich extra DLLs schreiben zu müssen?
Wichtig wäre, dass ich möglichst um die DLLs drumrum komme.
-
Blaze schrieb:
Gut, soweit war ich auch schon.
Oh sorry, den Teil deines Posts hab ich wohl nicht so richtig aufgenommen
Ohne DLL kenne ich keine Methode (denke auch nicht, dass sich da was findet, sonst wären die MsgProc-Hooks ja überflüssig).
-
Klar geht das:
1. EnableWindow(hWnd,FALSE) und schon kommen keine WM_MOUSEMOVE mehr an.
2. Subclassing: WM_NCHITTEST abfangen und HTTRANSPARENT zurückgeben.
3. Transparentes Fenster überdas Fenster legen...Und ich denke es wird noch ein paar andere Methoden außer Hooks geben...
-
Martin Richter schrieb:
Subclassing
Geht das denn mit einem Fenster eines fremden Prozesses? Oh, sehe grad, da steht nix von einem fremden Prozess. Hört sich trotzdem irgendwie danach an.
Und die anderen Sachen beeinträchtigen natürlich stark.
Blaze, wieso willst du denn unbedingt ohne DLL auskommen? Du müsstest sie ja auch nicht direkt beilegen, sondern kannst sie als Ressource einbinden, zur Laufzeit in's Temp-Verzeichnis entpacken und von da Laden.
-
Hooks sind mit Sicherheit invasiver als eine DLL die man injeziert und die einen subclass durchführt...
Der OP hat nicht gesagt was er will!
-
Martin Richter schrieb:
Hooks sind mit Sicherheit invasiver als eine DLL die man injeziert und die einen subclass durchführt...
Wohl wahr. Nur:
Blaze:"Ohne eine DLL schreiben zu müssen?"
-
Ich habe andere Möglichkeiten augezählt, die ohne gehen. Das einfachte ist ein EnableWindow(...,FALSE);
