In Hook auslösender Prozess ermitteln

[hesch21]

Hallo zusammen

Habe vermutlich wieder mal eine nasse Zündschnur. Ich habe ein Programm mit einer zugehörigen DLL. In der DLL hängt ein globaler Tastatur-Hook zum Abfangen einer Tastenkombination für eine Alarmmeldung. Das funktioniert alles bestens.
Nun möchte ich aber noch gerne wissen, in welchem Prozess die Tastenkombination ausgelöst wurde. Kann ja irgend ein Programm sein. So im Stil von mProc := GetCurrentProcessID;
Nur das geht natürlich nicht. Wenn ich das in die DLL einbaue, bekomme ich die PID meines eigenen Programms zurück und nicht diejenige, in welchem der Benutzer die Tastenkombination gedrückt hat.

Gibt es irgend eine Möglichkeit, die PID herauszufinden, aus der in die DLL/den Hook gesprungen wurde?

[baumina]

Ich befürchte, dass du die Taste abfängst, bevor sie das jeweilige Programm erreicht, aber mit folgendem könntest du das aktive Programm (Fenster) ermitteln:

Delphi-Quellcode:

var
   tid: Cardinal;
   hw: HWND;
begin
   hw := GetForegroundWindow;
   tid := GetWindowThreadProcessID(hw, nil);

[himitsu]

Bekommst du beim InstallHook nicht das Window geliefert, wo der Hook drangehängt wird?

Dort einfach das Fenster, bzw. die Fenster oder gleich die Prozess-ID merken.


Beim Fenster dann über GetWindowThreadProcessId.

[hesch21]

Danke für Eure Antworten, aber vermutlich habe ich mich unverständlich ausgedrückt. Die DLL mit dem Hook (genauer dem Hook-Call-Back) 'hängt' an einem Programm ALARM.EXE, welches seinerseits auch noch 'versteckt' läuft. Es ist nur ein Tray-Icon sichtbar.
Nun kann der Benutzer also irgendwo eine Tastenkombination (üblicherweise PageUp-PageDown) drücken und damit einen Alarm auslösen, der dann von ALARM.EXE über TCP/IP weiter geleitet wird. Das der Hintergrund und das funktioniert auch alles problemlos.
Nun kann der Benutzer aber wie gesagt die Tastenkombination in irgend einem Prozess betätigen, je nachdem, was er gerade am machen ist. Es geht sogar bei laufendem Bildschirmschoner oder mit Ctrl-Alt-Del blockiertem Rechner. So, und nun möchte ich einfach die PID wissen von dem (fremden) Prozess, der aktiv war, als der Benutzer die Tastenkombination gedrückt hat.

Der Ansatz von baumina tönt irgendwie nicht schlecht. CallBack setzt man ja immer zum Schluss Result := CallNextHookEx(HookTastatur, Code, wParam, lParam);
um (sofern ich das richtig verstehe), die Taste auch noch an das Programm/den Prozess weiter zu geben, wo die Eingabe erfolgt ist. Also muss ja 'irgendwo' bekannt sein, wie und wohin, aber eben...

himitsu, mit dem eigenen Fenster, Handle, PID, etc. habe ich wirklich keine Probleme.

[Zacherl]

Du hast himitsu missverstanden. Die Datenstruktur, die du in deinem Hook Callback geliefert bekommst, enthält seiner (und meiner) Meinung nach ein Feld mit dem Fensterhandle des momentan aktiven Programmes.

Darüber kannst du an die ProcessId und somit auch an den Prozessnamen gelangen.

[hesch21]

Ich hab's vermutet dass ich eine nasse Zündschnur habe, aber ich schnall's immer noch nicht. Die Struktur gemäss Microsoft http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx könnte höchstens beim nicht gerade sehr dokumentierten Feld dwExtraInfo ein Fensterhandle zum aktiven Programm enthalten.
Eine etwas seltsame Funktion hat der WPARAM der CallBack-Funktion:

Zitat:

Specifies whether the message was sent by the current thread. If the message was sent by the current thread, it is nonzero; otherwise, it is zero.

Ich werde nun mal ausprobieren, ob wirklich im dwExtraInfo ein Fensterhandle daher kommt.

[baumina]

Ich glaube die beiden meinten das InstallHook(Hwnd : Cardinal) wie hier beschrieben: http://www.delphi-treff.de/tutorials...-die-tastatur/

[hesch21]

hab's ausprobiert. Im dwExtraInfo kommt kein Fensterhandle daher.
Irgendwie brauche ich immer noch jemand, der bei mir den Rollladen hoch zieht. Und eigentlich bin ich beim Thema DLL und Hook ganz gut bewandert. Die Tutorials von Assarbad kenne ich seit Jahren und im Link, den mir baumina geschickt hat, ist ein Fehler: Maus- und Tastatur-Hook müssen nicht in eine DLL untergebracht werden (kann man sich IPC ersparen). Und wenn ich in diesem Beispiel von Assarbad die InstallHook function anschaue, resp. den ganzen Code, sehe ich keinen Sinn für WindowHandle. Wird gar nie verwendet.
Also Ihr seht, so ganz auf den Kopf gefallen bin ich eigentlich nicht, nur habe ich momentan echt das Gefühl, er stecke irgendwie im Sand.

[himitsu]

Ausgehend von http://www.delphi-treff.de/tutorials...-die-tastatur/ ,

was für ein Fenster kommt denn bei

Delphi-Quellcode:

function InstallHook(Hwnd: Cardinal): Boolean; stdcall;

an?

[Aphton]

Soweit ich mich richtig erinnere, sollte die PID (Prozess ID) jedem Prozess und NICHT jedem Modul (dll) zugeordnet sein. Dh. wenn du einen globalen Hook hast, was im Grunde einfach dem Betriebssystem sagt - "hey du, die Dll da -- lass alle mal laden"~ kannste in der Dll die ProzessID holen welche dann die des Prozesses ist. Es gibt diverse Enumerier-API Funktionen, mit denen du dann zum zugehörigen PID die Fenster Handles ermitteln kannst (sofern du sie brauchst)

Edit: Habs grad ausgetest und alles wie erwartet! GetCurrentProcessID() liefert ordentlich die PID des Prozesses!

[Zacherl]

Er sucht aber nicht die eigene ProcessId, sondern die PID des Prozesses, der grade eine Eingabe empfangen hat. Beim LLKEYBOARD_HOOK wird die DLL ja nichts injected, deshalb funktioniert deine Methode da nicht. Aber das schon genannte GetForegroundWindow, sollte eigentlich klappen.

[Sir Rufo]

Zitat:

Zitat von hesch21 (Beitrag 1239946)

hab's ausprobiert. Im dwExtraInfo kommt kein Fensterhandle daher.
Irgendwie brauche ich immer noch jemand, der bei mir den Rollladen hoch zieht. Und eigentlich bin ich beim Thema DLL und Hook ganz gut bewandert. Die Tutorials von Assarbad kenne ich seit Jahren und im Link, den mir baumina geschickt hat, ist ein Fehler: Maus- und Tastatur-Hook müssen nicht in eine DLL untergebracht werden (kann man sich IPC ersparen). Und wenn ich in diesem Beispiel von Assarbad die InstallHook function anschaue, resp. den ganzen Code, sehe ich keinen Sinn für WindowHandle. Wird gar nie verwendet.
Also Ihr seht, so ganz auf den Kopf gefallen bin ich eigentlich nicht, nur habe ich momentan echt das Gefühl, er stecke irgendwie im Sand.

Hmmm, warum hast du dann den KeyboardHook in einer DLL laufen?

Wenn diese DLL keinem anderen Programm bekannt ist, dann wird auch keiner darüber den Hook einhängen, sondern einen eigenen Hook einhängen (wie auch immer).

Und der Hook wird von der Tastatur ausgelöst und von keinem Programm/Form etc.
Die Tastatur sendet ein Ereignis (Taste gedrückt) und Windows schickt das durch den Hook.
Dann wird geschaut, was das aktive Fenster ist und diese Nachricht wird dann dorthin geschickt.

Und man kennt weder den Vorgänger, nach den Nachfolger beim Hook, sondern veranlasst nur, dass der nächste (wer immer das sein mag) diese Nachricht bearbeiten soll.

[hesch21]

Hallo himitsu

meine Hook-Start-Prozedur sieht wie folgt aus:

Delphi-Quellcode:

procedure HookOn(AppHandle: HWND; Welche: integer); stdcall;
begin
  if (Welche = 0) or (Welche = 2) then
     HookTastatur := SetWindowsHookEx(WH_KEYBOARD_LL, @CallBackDelHook, HInstance , 0);
  if (Welche = 1) or (Welche = 2) then
     HookMaus     := SetWindowsHookEx(WH_MOUSE_LL,    @MouseHookProc,   HInstance , 0);
  hApp         := AppHandle;
end;

Da in der DLL sowohl ein Maus- als auch ein Tastatur-Hook drin ist, kommt vom Programm, welches den Hook setzt, explizit das Window-Handle mit und die Steuerung, welche(r) Hook aktiviert werden soll.
Das Handle wird im aufrufenden Programm mittels WinHand := FindWindow ('TSILog', nil); ermittelt und explizit an die DLL übermittelt weil diese den Empfang der Tastenkombinationen über SendMessage(hApp, WM_USER + 4242, 0, 0); vollzieht.

Wie gesagt, das funktioniert alles.

Wenn das, was Aphton sagt, stimmen würde, müsste ja das mit mProz := GetCurrentProcessID; klappen, was ich bereits zu Beginn erwähnt habe, aber eindeutig nicht geht.

Und irgendwie ist mir immer noch nicht klar, warum Ihr so auf dem Handle oder der ID oder was auch immer des Prozesses oder Programmes herum reitet, welches den Hook gestartet hat. Die weiss ich ja. Aber wie komme ich an die PID, welche den Hook (oder von mir aus die DLL) aufruft?

[Sir Rufo]

Zitat:

Zitat von hesch21 (Beitrag 1239964)

Und irgendwie ist mir immer noch nicht klar, warum Ihr so auf dem Handle oder der ID oder was auch immer des Prozesses oder Programmes herum reitet, welches den Hook gestartet hat. Die weiss ich ja. Aber wie komme ich an die PID, welche den Hook (oder von mir aus die DLL) aufruft?

Weil die Nachricht vom Betriebssystem kommt und von keinem Programm.

Man kann sich in diese Nachrichtenschlange einhängen (hooken) also einen Einhänger (Hook) dort reinsetzen, da es sich um einen spezielle Nachrichttypen (WH_*) handelt, wo man sich einhängen kann.

Siehe Hooks

Zitat:

A hook is a point in the system message-handling mechanism where an application can install a subroutine to monitor the message traffic in the system and process certain types of messages before they reach the target window procedure.

Dein Denkfehler ist, dass das Tastaturereignis von einer Anwendung kommt.

Es ist aber genau umgekehrt. Die Tastatur weiß nichts von irgendeiner Anwendung. Die bekommt nur den Anschlag mit und erschreckt sich dabei so sehr, dass eine Nachricht an das Betriebssystem gegeben wird.

Dieses fühlt sich nun veranlasst eine Nachricht (WH_KEYBOARD_LL) zu verschicken.
Dann wird das aktive Fenster ermittelt und an die Anwendung wird das Tastaturereignis geschickt.

Also zum Zeitpunkt (WH_KEYBOARD_LL) hat sich noch keiner darum gekümmert, wer das Tastaturereignis empfangen soll.

[hesch21]

Hallo Sir Rufo

ehrlicherweise hab ich den Hook produktiv gar nicht in einer DLL. Aber ich hab keine andere schlaue Idee gehabt, wie ich bei dem direkt im Programm eingebundenen Hook heraus finden soll, aus welchem Prozess nun der Hook angesprochen wurde. Zumal mein Programm mit dem Hook auch noch ein Dienst ist, was die Sache auch nicht einfacher macht.
Ich habe mir nun aber gedacht, in der DLL müsste das doch gehen, da diese ja 'irgendwie' direkt von dem Prozess angesteuert wird, in dem das Tastenergeignis statt findet. Aber offenbar laufe ich auch da ins Leere.

[Sir Rufo]

Zitat:

Zitat von hesch21 (Beitrag 1239969)

Hallo Sir Rufo

ehrlicherweise hab ich den Hook produktiv gar nicht in einer DLL. Aber ich hab keine andere schlaue Idee gehabt, wie ich bei dem direkt im Programm eingebundenen Hook heraus finden soll, aus welchem Prozess nun der Hook angesprochen wurde. Zumal mein Programm mit dem Hook auch noch ein Dienst ist, was die Sache auch nicht einfacher macht.
Ich habe mir nun aber gedacht, in der DLL müsste das doch gehen, da diese ja 'irgendwie' direkt von dem Prozess angesteuert wird, in dem das Tastenergeignis statt findet. Aber offenbar laufe ich auch da ins Leere.

Ja, weil der Prozess kein Tastaturereignis auslöst.

Und man kann auch nicht feststellen, wer da alles einen Hook gesetzt hat.
Habe ich eine DLL, die einen Hook einhängt, dann kann ich alle die Prozesse bemerken (merken in der DLL), die den Hook mit dieser DLL einhängen. Alle anderen aber nicht - obwohl die trotzdem einen Hook haben könnten.

[Zacherl]

Zitat:

Zitat von hesch21 (Beitrag 1239964)

Aber wie komme ich an die PID, welche den Hook (oder von mir aus die DLL) aufruft?

Delphi-Quellcode:

var
  Wnd: HWND;
  ProcessId,
  ThreadId: DWord;
begin
  Wnd := GetForegroundWindow;
  ThreadId := GetWindowThreadProcessId(Wnd, ProcessId);
  { .. }

Zwar um 3 Ecken rum, aber es sollte funktionieren. Zumindest solange dein Hook Prozess unter der selben SessionId und auf dem selben Desktop läuft, wie das aktuelle Vordergrundfenster.

[Neutral General]

Zitat:

Zitat von Zacherl (Beitrag 1239971)

Zitat:

Zitat von hesch21 (Beitrag 1239964)

Aber wie komme ich an die PID, welche den Hook (oder von mir aus die DLL) aufruft?

Delphi-Quellcode:

var
  Wnd: HWND;
  ProcessId,
  ThreadId: DWord;
begin
  Wnd := GetForegroundWindow;
  ThreadId := GetWindowThreadProcessId(Wnd, ProcessId);
  { .. }

Aber auch nur wenn die Anwendung zufällig grad das Vordergrundfenster ist...

[Sir Rufo]

Zitat:

Zitat von Zacherl (Beitrag 1239971)

Zitat:

Zitat von hesch21 (Beitrag 1239964)

Aber wie komme ich an die PID, welche den Hook (oder von mir aus die DLL) aufruft?

Delphi-Quellcode:

var
  Wnd: HWND;
  ProcessId,
  ThreadId: DWord;
begin
  Wnd := GetForegroundWindow;
  ThreadId := GetWindowThreadProcessId(Wnd, ProcessId);
  { .. }

Zwar um 3 Ecken rum, aber es sollte funktionieren. Zumindest solange dein Hook Prozess unter der selben SessionId und auf dem selben Desktop läuft, wie das aktuelle Vordergrundfenster.

Das wird schwierig, denn das soll ja in einem Dienst laufen ... ;)

[hesch21]

Hat sich etwas überschnitten. Was Du mir schön plastisch erklärst ist mir eigentlich schön klar und ich weiss schon, dass das Keyboard-Event zum CallBack vom OS mehr oder weniger direkt von der Tastatur kommt. Aber etwas dämlich und ebenso plastisch ausgedrückt weiss das OS mit Garantie auch, welcher Prozess zu dem Zeitpunkt gerade aktiv ist. Und das möchte ich auch gerne wissen. Aber wie bringt man dieses liebe Betriebssystem dazu, dieses Geheimnis preis zu geben?

[Zacherl]

Zitat:

Zitat von Neutral General (Beitrag 1239972)

Aber auch nur wenn die Anwendung zufällig grad das Vordergrundfenster ist...

Mit Zufall hat das nichts zu tun. Tastatureingaben gehen nunmal in der Regel an das Vordergrundfenster ("Tastaturfocus-Fenster"). Mit Ausnahme von Hotkeys, etc.

Zitat:

Zitat von Sir Rufo (Beitrag 1239973)

Das wird schwierig, denn das soll ja in einem Dienst laufen ... ;)

Dann würde ich mal ganz dezent vorschlagen die Idee mit dem Tastatur Hook zu verwerfen und stattdessen RegisterHotkey() zu nehmen. Alternativ auch einen GetMessage Hook in einer DLL.

[hesch21]

Wir machen offenbar einen Wettlauf. Ich versuch's. Danke!

[Sir Rufo]

Zitat:

Zitat von hesch21 (Beitrag 1239974)

Hat sich etwas überschnitten. Was Du mir schön plastisch erklärst ist mir eigentlich schön klar und ich weiss schon, dass das Keyboard-Event zum CallBack vom OS mehr oder weniger direkt von der Tastatur kommt. Aber etwas dämlich und ebenso plastisch ausgedrückt weiss das OS mit Garantie auch, welcher Prozess zu dem Zeitpunkt gerade aktiv ist. Und das möchte ich auch gerne wissen. Aber wie bringt man dieses liebe Betriebssystem dazu, dieses Geheimnis preis zu geben?

So wie hier schon die ganze Zeit geschrieben

Zitat:

Zitat von Zacherl (Beitrag 1239971)

Zitat:

Zitat von hesch21 (Beitrag 1239964)

Aber wie komme ich an die PID, welche den Hook (oder von mir aus die DLL) aufruft?

Delphi-Quellcode:

var
  Wnd: HWND;
  ProcessId,
  ThreadId: DWord;
begin
  Wnd := GetForegroundWindow;
  ThreadId := GetWindowThreadProcessId(Wnd, ProcessId);
  { .. }

Zwar um 3 Ecken rum, aber es sollte funktionieren. Zumindest solange dein Hook Prozess unter der selben SessionId und auf dem selben Desktop läuft, wie das aktuelle Vordergrundfenster.

Problematisch ist nur, dass du dich in einem Dienst befindest und der hat keine aktiven Anwendungen ... bzw. der sieht nicht das, was du möchtest, dass er sieht ;)

[Sir Rufo]

Zitat:

Zitat von Zacherl (Beitrag 1239976)

Zitat:

Zitat von Neutral General (Beitrag 1239972)

Aber auch nur wenn die Anwendung zufällig grad das Vordergrundfenster ist...

Mit Zufall hat das nichts zu tun. Tastatureingaben gehen nunmal in der Regel an das Vordergrundfenster ("Tastaturfocus-Fenster"). Mit Ausnahme von Hotkeys, etc.

Zitat:

Zitat von Sir Rufo (Beitrag 1239973)

Das wird schwierig, denn das soll ja in einem Dienst laufen ... ;)

Dann würde ich mal ganz dezent vorschlagen die Idee mit dem Tastatur Hook zu verwerfen und stattdessen RegisterHotkey() zu nehmen. Alternativ auch einen GetMessage Hook in einer DLL.

Wenn ich so etwas implementieren müsste, dann würde pro Session eine Anwendung (definitiv kein Dienst) laufen, die einen Keyboard-Hook hat. Diese Anwendung kann dann auch schauen, welche Anwendung zum Zeitpunkt des Hook-CallBack-Aufrufs gerade im Vordergrund ist.

Da ja schon eh eine kleine Anwendung laufen soll (die mit dem Trayicon), wäre genau diese der richtige Ort.

[Aphton]

Willst du (nur) alle durch Anwendungen generierte Key-Message (SendInput z.B.) abfangen (und nicht unbedingt durch den User per Keyboard-Input)?

Falls dem so ist, bist du zu 50% fertig - den globalen Hook hast du bereits ja. Die restlichen 50% bestehen aus folgendem:
In deinem Hook (dll) wendest du eine andere Art von hook an (API-Hook, IAT-Hooking, usw usf..) wo du alle API Befehle, die in irgendeiner Art und Weise Keystrokes generieren können, hookst). Dann monitorst du genau diese und sobald sie aufgerufen werden, schickst du deiner APP ne Message mit "Hey, kuck mal, der hier (PID/hWnd) generiert grad Keystrokes!"

[hesch21]

Erst mal Danke für Eure Hilfe. Die Lösung mit dem GetForeGroundWindow funktioniert da ich ja noch neben dem Dienst ein Miniprogramm am laufen habe, welches jeweils vom Dienst auf den gerade aktuellen Desktop geschmissen wird.

Nun bin ich aber bei meiner Rumspielerei mit den Hooks noch auf ein anderes Problem gestossen. Beim Maus-Hook gibt es in der Struktur den Wert wHitTestCode und der müsste mit einem Wert gemäss WM_NCHITTEST bestückt werden. Bei mir kommt aber immer nur 0 zurück. Habt Ihr eine Ahnung, was ich falsch mache? Hier der Code:

Delphi-Quellcode:

type
 PMSDLLHookInfo = ^TMSDLLHookInfo;
 tagMSDLLHOOKSTRUCT = packed record
    POINT       : TPoint;
    Handle      : DWORD;
    wHitTestCode: integer;
    dwExtraInfo : DWORD;
 end;
 TMSDLLHookInfo = tagMSDLLHOOKSTRUCT;

var HookMaus          : HHook;
var hApp              : HWND;

function MouseHookProc(Code: Integer; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
const WM_XBUTTONDOWN   = $020B;
const WM_XBUTTONUP     = $020C;
const WM_XBUTTONDBLCLK = $020D;
var Wnd     : HWND;
var PID     : DWord;
var TID     : DWord;
var mVKCode : integer;
var mUpDown : integer;
var XKord   : integer;
var YKord   : integer;
var woHit   : string;
var wasHit  : string;

begin
  if (Code = HC_ACTION) and (wParam <> WM_MOUSEMOVE) and (wParam <> WM_NCMOUSEMOVE) then
     begin
     Wnd     := GetForeGroundWindow;
     TID     := GetWindowThreadProcessId(Wnd, PID);
     MUpDown := wParam;
     case wParam of
          WM_LBUTTONDBLCLK : WasHit := 'L-ButtonDBLClick';
          WM_LBUTTONDOWN   : WasHit := 'L-ButtonDown';
          WM_LBUTTONUP     : WasHit := 'L-ButtonUp';
          WM_MBUTTONDBLCLK : WasHit := 'M-ButtonDBLClick';
          WM_MBUTTONDOWN   : WasHit := 'M ButtonDown';
          WM_MBUTTONUP     : WasHit := 'M-ButtonUp';
          WM_RBUTTONDBLCLK : WasHit := 'R-ButtonDBLClick';
          WM_RBUTTONDOWN   : WasHit := 'R-ButtonDown';
          WM_RBUTTONUP     : WasHit := 'R-ButtonUp';
          WM_XBUTTONDBLCLK : WasHit := 'X-ButtonDBLClick';
          WM_XBUTTONDOWN   : WasHit := 'X-ButtonDown';
          WM_XBUTTONUP     : WasHit := 'X-ButtonUp';
          WM_MOUSEHOVER    : WasHit := 'MouseHover';
          WM_MOUSELEAVE    : WasHit := 'MouseLeave';
          WM_MOUSEMOVE     : WasHit := 'MouseMove';
          WM_MOUSEWHEEL    : WasHit := 'MouseWheel';
          WM_MOUSEACTIVATE : WasHit := 'MouseActivate';
          WM_NCLBUTTONDOWN : WasHit := 'NCL-L-ButtonDown';
     else
          WasHit := IntToStr(wparam);
     end;
     XKord   := PMSDLLHookInfo(lParam).POINT.X;
     YKord   := PMSDLLHookInfo(lParam).POINT.Y;
     mVKCode := PMSDLLHookInfo(lParam).wHitTestCode;
     case mVKCode of
          HTBORDER         : WoHit := 'Border';
          HTBOTTOM         : WoHit := 'Bottom';
          HTBOTTOMLEFT     : WoHit := 'BottomLeft';
          HTBOTTOMRIGHT    : WoHit := 'BottomRight';
          HTCAPTION        : WoHit := 'Caption';
          HTCLIENT         : WoHit := 'Client';
          HTCLOSE          : WoHit := 'Close';
          HTERROR          : WoHit := 'Error';
          HTHELP           : WoHit := 'Help';
          HTHSCROLL        : WoHit := 'Scroll';
          HTLEFT           : WoHit := 'Left';
          HTMENU           : WoHit := 'Menu';
          HTREDUCE         : WoHit := 'Reduce';
          HTNOWHERE        : WoHit := 'Nowhere';
          HTRIGHT          : WoHit := 'Right';
          HTSIZE           : WoHit := 'Size';
          HTSYSMENU        : WoHit := 'SysMenu';
          HTTOP            : WoHit := 'Top';
          HTTOPLEFT        : WoHit := 'TopLeft';
          HTTOPRIGHT       : WoHit := 'TopRight';
          HTTRANSPARENT    : WoHit := 'Transparent';
          HTVSCROLL        : WoHit := 'V-Scroll';
          HTZOOM           : WoHit := 'Zoom';
     else
          WoHit := IntToStr(mVKCode);
     end;

anzumerken wäre, dass die x- und y-Koordinaten richtig aus der Struktur ausgelesen werden.

[Sir Rufo]

Bist du dir sicher, dass du weißt, was du da gerade tust? :gruebel:

Ich fürchte mal nicht ... denn

• WH_MOUSE_LL -> MSLLHOOKSTRUCT
• WH_MOUSE -> MOUSEHOOKSTRUCT

Du sprichst immer von globalen (also den LowLevel) Hooks, benutzt aber die Struktur für den normalen Hook.
Welchen Hook willst du denn jetzt benutzen?

[hesch21]

Upps!
war vermutlich Wunschdenken! Ich bin vorderhand wirklich nur am rumspielen mit dem Maushook und die Anzeige, wo geklickt wurde, wäre echt schön gewesen. Das scheint aber mit der korrekten Low-Level-Struktur leider nicht möglich zu sein. Da gibt es nichts ähnliches wie HitTestCode. Schade.