Nachrichten vollkommen abfangen

[OrallY]

Hi,

ist es möglich eine Nachricht, die an eine fremde Anwendung geschickt wird, abzufangen und zu verhindern, dass die Nachricht die Anwendung erreicht?

Hintergrund der Frage ist das Problem, dass ich gerne Mousemove-Messages abfangen möchte, da diese zu unliebsamen Neuzeichnungen einiger Controls führt. Zwar habe ich schon versucht die Mousemove-Nachrichten mit einem LLMouseHock abzufangen, jedoch hat dies zur Folge, dass die Maus einfach stehen bleibt.

Vielleicht hätte jemand noch einen anderen Vorschlag, wie ich verhindern kann, dass sich einige Controls wegen Highlighting neuzeichnen. Ich arbeite zur Zeit an einem Programm, das direkt auf den Desktop zeichnet. Wird nun ein solcher Highlight aktiv und das Control neugezeichnet, entstehen beim löschen des Gemalten Artefakte (gemalte und gelöscht wird mit dem selben Inverse-Pen).

Ich habe auch schon ausprobiert, die Steuerelemnte einfach für den Zeitraum, wo sich die Maus über sie bewegt zu deaktivieren, jedoch bleibt zum einen beispielsweise das Osziloskop von Winamp stehen. Außerdem ist es doch reichlich ärgerlich, wenn das Programm aus irgendwelchen Grünen absürtzen sollte und deaktivierte Controls zurücklässt.

Eine andere Idee war ein transparentes Fenster, dass ich über den Bildschirm lege und dann dort drauf zeichne. Jedoch führte dies zu Darstellungsproblemen mit meiner TV-Software und teilweise flackerte der Bildschirm, wenn ich das Fenster wieder versteckte.

Vielen Dank im Vorraus

greez

[Mephistopheles]

Zitat von OrallY:

ist es möglich eine Nachricht, die an eine fremde Anwendung geschickt wird, abzufangen und zu verhindern, dass die Nachricht die Anwendung erreicht?

Hooks oder DLL-Injection mit Subclassing. Also ja.

Zitat von OrallY:

Hintergrund der Frage ist das Problem, dass ich gerne Mousemove-Messages abfangen möchte, da diese zu unliebsamen Neuzeichnungen einiger Controls führt. Zwar habe ich schon versucht die Mousemove-Nachrichten mit einem LLMouseHock abzufangen, jedoch hat dies zur Folge, dass die Maus einfach stehen bleibt.

Reicht nicht ein normaler Maushook auch? Also ohne LL?

Zitat von OrallY:

Vielleicht hätte jemand noch einen anderen Vorschlag, wie ich verhindern kann, dass sich einige Controls wegen Highlighting neuzeichnen. Ich arbeite zur Zeit an einem Programm, das direkt auf den Desktop zeichnet. Wird nun ein solcher Highlight aktiv und das Control neugezeichnet, entstehen beim löschen des Gemalten Artefakte (gemalte und gelöscht wird mit dem selben Inverse-Pen).

Zeichnest du während einer Mausaktion? Dann wäre vermutlich Mousecapturing was für dich. Dabei werden z.B. die Fenster über welche du hoverst keine Mausnachrichten erhalten, denn beim Mousecapturing bekommst du alle Mausnachrichten.

Zitat von OrallY:

Eine andere Idee war ein transparentes Fenster, dass ich über den Bildschirm lege und dann dort drauf zeichne. Jedoch führte dies zu Darstellungsproblemen mit meiner TV-Software und teilweise flackerte der Bildschirm, wenn ich das Fenster wieder versteckte.

Das sollte klar werden, wenn man weiß, daß es neben der guten alten GDI ja auch noch DirectDraw usw. gibt.

[OrallY]

Erstmal vielen Dank für die Antwort. Ich hatte die Hoffnung schon aufgegeben .

Zitat von Mephistopheles:

Hooks oder DLL-Injection mit Subclassing. Also ja.

Könntest du das bitte genauer erläutern?

Zitat von Mephistopheles:

Reicht nicht ein normaler Maushook auch? Also ohne LL?

Wenn man es so macht wie ich, dann nein. Meine Vorgehensweise bisher war, einen LowLevel-MouseHook zu erstellen und durch Nichtaufruf von CallNextHookEx die Mausnachrichten daran zu hindern, an weitere Fenster weitergeleitet zu werden.
Meiner Meinung nach eine schlechte Lösung, auf die ich leider aus Ermangelung weitere Lösungen zurückgreifen musste .

Zitat von Mephistopheles:

Zeichnest du während einer Mausaktion? Dann wäre vermutlich Mousecapturing was für dich. Dabei werden z.B. die Fenster über welche du hoverst keine Mausnachrichten erhalten, denn beim Mousecapturing bekommst du alle Mausnachrichten.

Das ist schon mal ein sehr guter Hinweis! thx. Allerdings funktioniert das Mousecapturing ja nur, wenn ich die Maus innerhalb des eigenen Fensters drücke, nicht aber, wenn außerhalb gedrückt wird. Deshalb ja auch der LL-Mousehook, da der Anwender überall zu zeichnen anfangen können soll. (Zumal meine Anwendung nur ein Messageonly-Window besitzt).

Also wäre das Abfangen von Mausklicks außerhalb des Clientbereichs mittels DLL-Injection mit Subclassing (was immer das auch sein mag) möglich? Wenn ja, wie? Und wie ginge es mit Hooks? (Fragen über Fragen ).

greez

[Chewie]

Also was Subclassing ist, erfährst du in den ersten Kapiteln von Luckies Winapi-Tutorials.
Nur erfährst du da halt nicht, wie du deinen Code in den Prozess überhaupt erst reinkriegst

[Mephistopheles]

Die Zeit is kurz, die Kunst ist lang.

Subclassing würde dir erlauben tatsächlich von einem Fenster die Mausnachrichten verhindern. Allerdings bliebe das Problem, daß dieses "Fenster" ja herausfinden muß, ab wann es wieder Mausnachrichten empfangen darf.

Mich würde erst einmal interessieren, was genau du erreichen möchtest, denn dies wäre hier wohl besser. Ich habe noch nicht einmal deinen aktuellen Lösungsansatz komplett deiner Beschreibung entnehmen können. Hingegen zu einer bestimmten Problemstellung kann man eventuell Alternativen finden.

[c113plpbr]

Ich weis nicht genau um was es genau geht, aber wenn du das versenden von WindowMessages verhindern willst, könnte dir da ein Globaler API-Hook auf die SendMessageA & SendMessageW funktionen vielleicht weiterhelfen.

Um herauszufinden, wann die Messages abgefangen werden müssen, und wann nicht, könnte man einen Globalen Mutex verwenden.

All dies ist eigentlich relativ einfach zu realisieren, mit Hilfe einer Library: MadCodeHook
Die MadCodeHook library gibt es unter http://www.madshi.net/ für nichtkommerzielle Zwecke kostenlos zum Download.

ciao, Philipp

[Mephistopheles]

Zitat von c113plpbr:

All dies ist eigentlich relativ einfach zu realisieren, mit Hilfe einer Library: MadCodeHook
Die MadCodeHook library gibt es unter http://www.madshi.net/ für nichtkommerzielle Zwecke kostenlos zum Download.

Und sehr instabil (bezieht sich nur auf das besagte Produkt!).

Und schonmal geguckt wie oft diese APIs so durchschnittlich aufgerufen werden? Da tut jeder zusätzliche CPU-Zyklus weh. Aua.

[c113plpbr]

Zitat von Mephistopheles:

Zitat von c113plpbr:

All dies ist eigentlich relativ einfach zu realisieren, mit Hilfe einer Library: MadCodeHook
Die MadCodeHook library gibt es unter http://www.madshi.net/ für nichtkommerzielle Zwecke kostenlos zum Download.

Und sehr instabil (bezieht sich nur auf das besagte Produkt!).

Keineswegs. Bisher hat noch alles problemlos funktioniert, was ich damit gemacht habe!

Zitat von Mephistopheles:

Und schonmal geguckt wie oft diese APIs so durchschnittlich aufgerufen werden? Da tut jeder zusätzliche CPU-Zyklus weh. Aua.

Ja, schon klar, aber Windowseigene Methoden tun nichts anderes. Nur eben auf Systemwegen.
Und, zur Geschwindigkeit: Ein DirectX-Hook (wie er z.B. in Fraps verwendet wird), der vllt. noch die ein oder andere Funktion aufruft, kostet vielleicht 2 Frames (bei ner durchschnittlichen Framerate von 60fps). Und das ist nun wirklich wenig ... und nun sag mir nicht, dass diese SendMessage-Funktionen dauerhaft öfter als 60 mal pro sekunde aufgerufen werden!

[edit]
Achja, die Entwickler von Detours (ist sowas ähnliches, nur von M$) haben den Zeitunterschied (bei leeren Funktionen) mal nachgemessen:
Direktaufruf: 113 ns
Mit Detours: 145 ns
und das ist sogut wie nichts ...
[/edit]

ciao, Philipp

[Mephistopheles]

Zitat von c113plpbr:

Keineswegs. Bisher hat noch alles problemlos funktioniert, was ich damit gemacht habe!

Ist das repräsentativ? Bei mir war bereits das Gegenteil der Fall.

Zitat von c113plpbr:

Ja, schon klar, aber Windowseigene Methoden tun nichts anderes. Nur eben auf Systemwegen.
Und, zur Geschwindigkeit: Ein DirectX-Hook (wie er z.B. in Fraps verwendet wird), der vllt. noch die ein oder andere Funktion aufruft, kostet vielleicht 2 Frames (bei ner durchschnittlichen Framerate von 60fps). Und das ist nun wirklich wenig ... und nun sag mir nicht, dass diese SendMessage-Funktionen dauerhaft öfter als 60 mal pro sekunde aufgerufen werden!

Das kommt immer auf die Menge von Fenstern an. Prinzipiell magst du recht haben. Aber an welcher Prozessorleistung (CPU + GPU) hast du denn die 2 FPS gemessen? Ich denke mal an meinem K6-II 450 (16 MB Grafikkarte) war es nicht, oder? Und ja - auch wenn Entwicklerrechner oft sehr leistungsfähig sind - die meisten Rechner kommen nicht an einen Pentium HT ran.

Zitat von c113plpbr:

[edit]
Achja, die Entwickler von Detours (ist sowas ähnliches, nur von M$) haben den Zeitunterschied (bei leeren Funktionen) mal nachgemessen:
Direktaufruf: 113 ns
Mit Detours: 145 ns
und das ist sogut wie nichts ...
[/edit]

LOL - und wieder die Frage nach dem Rechner. Außerdem ist hier die Quantität der Aufrufe ganz offensichtlich sehr entscheidend. Und SendMessage() dürfte zu den häufigsten Funktionen gehören.

[c113plpbr]

Zitat von Mephistopheles:

Ist das repräsentativ? Bei mir war bereits das Gegenteil der Fall.

Dann hast du wohl etwas falsch gemacht ...

Zitat von Mephistopheles:

Das kommt immer auf die Menge von Fenstern an. Prinzipiell magst du recht haben. Aber an welcher Prozessorleistung (CPU + GPU) hast du denn die 2 FPS gemessen? Ich denke mal an meinem K6-II 450 (16 MB Grafikkarte) war es nicht, oder? Und ja - auch wenn Entwicklerrechner oft sehr leistungsfähig sind - die meisten Rechner kommen nicht an einen Pentium HT ran.

(es war ja nur ein beispiel) Siehe mein Nachtrag.

[edit]
Man, warum musst du alles, was ich sage so kritisieren, als ob ich überhaupt keine ahnung hätte?
bisher hab ich von dir nur behauptungen gehört, keine beweise. Beweise hab ich ja schon (im gegensatz zu dir) versucht aufzubringen ...

Zitat von Mephistopheles:

LOL - und wieder die Frage nach dem Rechner. Außerdem ist hier die Quantität der Aufrufe ganz offensichtlich sehr entscheidend. Und SendMessage() dürfte zu den häufigsten Funktionen gehören.

Und selbst wenn 1000 aufrufe pro sekunde kämen (was relativ unwarscheinlich ist), wäre api hooking nicht viel langsamer als windowseigene methoden.
Aber ich habe nie behauptet, dass dies die "ultimative lösung" ist, es war nur ein vorschlag. Und welchen weg OrallY hinterher geht, bleibt doch wohl noch ihm überlassen.
[/edit]

ciao, Philipp