Einzelnen Beitrag anzeigen

EWeiss
(Gast)

n/a Beiträge
 
#3

AW: KeyHook Irreführend

  Alt 13. Apr 2011, 11:54
Zitat:
Davon gibt es sicherlich tausende, jeder kann eine DLL so nennen.

Normalerweise wird so eine DLL im System registriert, so dass diese beim Start jeder Anwendung mitgeladen wird
und so alle Tastatureingaben verarbeiten kann, egal welche Anwendung den Focus hat.
Der Name der DLL ist eigentlich unwichtig.
Kompliziert wirds wenn 64- und 32-Bit-Anwendungen gemischt auftreten.
Warum ?
Wird bei mir dynamisch über loadlibrary iniziiert.
Und NUR! für meine Anwendung gedacht.

Zitat:
Von was für einer SuperClass ist hier die Rede, aus welcher Komponentensammlung stammt diese
und was machen diese Klassen, ist Quellcode vorhanden, kann dieser gepatcht werden?
Die SuperClass nenn ich einfach mal so!
Verwaltet alle meine Controls "Button und Image" in einer einzigen WinProc.
Also alle Controls/Komponente oder wie auch immer die über meine DLL in der HauptAnwendung erstellt werden.

Zitat:
Normalerweise verwenden Musikinstrumente die Midi-Schnittstelle, dieses scheinbar nicht.
Warum auch ?
MMSystem dürfte für meine zwecke reichen. Wenn man es genau benennen will "winmm.dll"
Dafür muss ich keine Midi Schnittstelle (Siehe Midi Componente) verwenden.
Ausgenommen jetzt beim konvertieren von meinem Format nach MIDI da benötige ich zumindest den Header
um die Daten Ordnungsgemäß konvertieren und abspeichern zu können.

Zitat:
Normalerweise meldet man bei der KeyHook.dll das Fenster(Handle) an, das über die Tasten informiert werden soll,
diese verarbeitet, oder auch nicht und damit an die Anwendung weitergibt, die derzeit den Focus hat.
Habe nichts anderes gemacht !!

Delphi-Quellcode:
procedure InitKeyHook;
begin

  lpHookRec := nil;

  LibLoadSuccess := FALSE;

  @GetHookRecPointer := nil;
  @StartKeyBoardHook := nil;
  @StopKeyBoardHook := nil;

  // Hook DLL laden
  hHookLib := LoadLibrary('KeyHook.DLL');
  // Laden erfolgreich?
  if hHookLib <> 0 then
  begin
    // Functions adressen einlesen
    @GetHookRecPointer :=
      GetProcAddress(hHookLib, 'GETHOOKRECPOINTER');
    @StartKeyBoardHook :=
      GetProcAddress(hHookLib, 'STARTKEYBOARDHOOK');
    @StopKeyBoardHook :=
      GetProcAddress(hHookLib, 'STOPKEYBOARDHOOK');

    // Alle Functionen vorhanden?
    if ((@GetHookRecPointer <> nil) and
      (@StartKeyBoardHook <> nil) and
      (@StopKeyBoardHook <> nil)) then
    begin
      LibLoadSuccess := TRUE;
      // Hole den Zeiger vom Hook Record
      lpHookRec := GetHookRecPointer;
       // Erfolgreich?
      if (lpHookRec <> nil) then
      begin
        // Record füllen
        lpHookRec^.TheHookHandle := 0;
        lpHookRec^.TheCtrlWinHandle := MainHandle; // Angemeldetes FensterHandle (Sollte OK sein)
        lpHookRec^.TheKeyCount := 0;
        // Keyboard Hook starten
        StartKeyBoardHook;
      end;
    end
    else
    begin
      // Wenn nicht alle Functionen gefunden wurden.
      FreeLibrary(hHookLib);
      hHookLib := 0;
      @GetHookRecPointer := nil;
      @StartKeyBoardHook := nil;
      @StopKeyBoardHook := nil;
    end;
  end;

end;
Zitat:
Der Datenaustausch zwischen der DLL und der Anwendung kann auch über Nachrichten erfolgen,
aber nicht unbedingt über WM_KEYDOWN und WM_KEYUP.
Jo alternativ über einen Timer sehe ich aber nicht als sinnvoll an.

Zitat:
Ein Keyboard-Hook blockt keine Anwendung, bitte etwas genauer formulieren.
Meine Button lösen kein Event mehr aus nach einem klick.

Zitat:
Was verstehst du unter "blockt"?
Der Begriff scheint mir in Zusammenhang mit SetFocus nicht sinnvoll.
Meine Button bekommen nicht mehr den Focus sobald ich den Focus auf die HauptAnwendung lege.

gruss

Geändert von EWeiss (13. Apr 2011 um 12:45 Uhr)
  Mit Zitat antworten Zitat