In Hook auslösender Prozess ermitteln

[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 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.

[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 von 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.

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.