KeyHook Irreführend

[EWeiss]

Habe mal für mein Piano eine KeyHook.dll eingebunden.

Mein Problem vorher
Wenn ich ohne Keyhook arbeite und die Tastatur für die Klaviertasten freigebe
kann ich alle meine Button nicht mehr bedienen da diese innerhalb der SuperClass nach
If WinHandle = GetFocus then abfragen.

Wenn ich bedingt durch die Tastaturzuweisung den Focus auf das MainHandle lege
schlägt diese Abfrage natürlich fehl.

Jetzt habe ich den Keyhook eingebaut aber das problem bleibt bestehn da ich als Hook Handle
ja auch wieder das Handle der MainForm angegeben habe.

Zitat:

Was ich auch nicht verstehe warum muss man dann obwohl ein Hook installiert ist seine
Anweisungen noch über WM_KEYDOWN: und WM_KEYUP: übergeben.

OK das ist quatsch irgendwo müssen die Keyevents ja übergeben werden.


Welchen Sinn macht dann ein Hook?
Wenn er die Anwendung genauso blockt wie vorher.

Bei bedarf sende ich mal den Quelltext vom Hook.

PS:
Wie kann ich SetFocus behandeln das nicht die anderen Controls geblockt werden.

gruss

[Blup]

Irgendwie verwirrt mich der ganze Beitrag etwas.

Zitat von EWeiss:

Habe mal für mein Piano eine KeyHook.dll eingebunden.

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.

Zitat von EWeiss:

Mein Problem vorher
Wenn ich ohne Keyhook arbeite und die Tastatur für die Klaviertasten freigebe
kann ich alle meine Button nicht mehr bedienen da diese innerhalb der SuperClass nach
If WinHandle = GetFocus then abfragen.

Wenn ich bedingt durch die Tastaturzuweisung den Focus auf das MainHandle lege
schlägt diese Abfrage natürlich fehl.

Normalerweise verwenden Musikinstrumente die Midi-Schnittstelle, dieses scheinbar nicht.
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?

Zitat von EWeiss:

Jetzt habe ich den Keyhook eingebaut aber das problem bleibt bestehn da ich als Hook Handle
ja auch wieder das Handle der MainForm angegeben habe.

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.

Zitat von EWeiss:

Zitat:

Was ich auch nicht verstehe warum muss man dann obwohl ein Hook installiert ist seine
Anweisungen noch über WM_KEYDOWN: und WM_KEYUP: übergeben.

OK das ist quatsch irgendwo müssen die Keyevents ja übergeben werden.

Der Datenaustausch zwischen der DLL und der Anwendung kann auch über Nachrichten erfolgen,
aber nicht unbedingt über WM_KEYDOWN und WM_KEYUP.

Zitat von EWeiss:

Welchen Sinn macht dann ein Hook?
Wenn er die Anwendung genauso blockt wie vorher.

Ein Keyboard-Hook blockt keine Anwendung, bitte etwas genauer formulieren.

Zitat von EWeiss:

Bei bedarf sende ich mal den Quelltext vom Hook.

Den Quelltext der KeyHook.dll und den Quelltext in deiner Anwendung.

Zitat von EWeiss:

PS:
Wie kann ich SetFocus behandeln das nicht die anderen Controls geblockt werden.

Was verstehst du unter "blockt"?
Der Begriff scheint mir in Zusammenhang mit SetFocus nicht sinnvoll.

[EWeiss]

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

[Blup]

Zitat von EWeiss:

Warum ?
Wird bei mir dynamisch über loadlibrary iniziiert.
Und NUR! für meine Anwendung gedacht.

Deine Anwendung wird dann aber auch nur auf das Instrument reagieren, solange diese den Focus hat.
Eine DLL ist dafür nicht erforderlich, einen Hook innerhalb deiner Anwendung kannst du jederzeit setzen.

Zitat von EWeiss:

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.

Ich halte diese Form des Anwendungsaufbaus nicht für optimal.
Wenn tatsächlich alle Nachrichten in einer WinProc landen, wird eigentlich überhaupt kein Hook benötigt.
Du bekommst alle Tastaturereignisse und entscheidest selbst ob diese an die jeweils orginale WindProc weitergegeben oder anderweitig verarbeitet werden.

Zitat von EWeiss:

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.

Wenn die Daten über eine separate Schnittstelle kommen, kann die Anwendung diese empfangen und verarbeiten, ohne Rücksicht darauf, welche Anwendung gerade den Focus hat.

Der gepostete Code bezieht sich nur darauf, wie die DLL geladen wird.
Wichtig wäre aber, was macht die DLL wenn ein Ereignis eintritt, bzw. wie gibt diese das Ereignis an die Anwendung weiter. Wie reagiert deine Anwendung auf das Ereignis, das von der DLL an die Anwendung weiter gereicht wird.

Zitat von EWeiss:

Meine Button lösen kein Event mehr aus nach einem klick.
...
Meine Button bekommen nicht mehr den Focus sobald ich den Focus auf die HauptAnwendung lege.

Da schein in deiner speziellen WinProc etwas nicht so zu laufen wie es sollte.
Hier wäre auch etwas Code angebracht, insbesondere:
- Wenn eine Nachricht selbst verarbeitet wird, stimmt der Rückgabewert, werden zusammengehörige Nachrichten auch auf die selbe Weise verarbeitet (Stichwort KeyDown, KeyUp).
- Wie wird sichergestellt, dass die richtige orginale WindProc des Steuerelements aufgerufen wird, zu dem das Handle der Nachricht gehört.
- Warum wird der Focus verändert und für was dient dieses "GetFocus" in deiner SuperClass überhaupt?

Häng am besten mal das Projekt an deinen Beitrag.

[EWeiss]

Zitat:

Häng am besten mal das Projekt an deinen Beitrag.

Sorry denke mal nicht.

So wie ich hier teilweise wegen meinem programmierstil runtergemacht wurde werde
ich den source mal nicht veröffentlichen.

Denke das da eh niemand so richtig durchblickt. (Nur eine Annahme)

Muss mein projekt halt nochmal durchkramen denke irgendwo
werde ich das problem schon lokalisieren.

Zitat:

Deine Anwendung wird dann aber auch nur auf das Instrument reagieren, solange diese den Focus hat.
Eine DLL ist dafür nicht erforderlich, einen Hook innerhalb deiner Anwendung kannst du jederzeit setzen.

Den Focus hat die MainForm..
Und nur dann wenn ich die Funktion über Keyboard freischalte dann reagiert das Instrument auf die Tastatur eingabe
weil dieses als Child auf der MainForm aufgesetzt ist.
Die DLL benötige ich schon weil ich ansonsten erst auf die KeyTasten klicken muss damit diese
den Focus erhalten.

Zitat:

Ich halte diese Form des Anwendungsaufbaus nicht für optimal.
Wenn tatsächlich alle Nachrichten in einer WinProc landen, wird eigentlich überhaupt kein Hook benötigt.

Grafische Funktionen!
Nicht mehr nicht weniger.
google mal nach "Superclassing"
Ist sehe nichts verkehrtes daran diese zu verwenden und einzusetzen.
Soweit diese Richtig verwaltet wird.. ( denke da ist noch ein Problem bei mir)

Zitat:

Da schein in deiner speziellen WinProc etwas nicht so zu laufen wie es sollte.

Davon muss ich ausgehen da es ansonsten ja funktionieren würde.

gruss

[Luckie]

Zitat von EWeiss:

Denke das da eh niemand so richtig durchblickt. (Nur eine Annahme)

Du aber anscheinend auch nicht. Und das könnte wiederum an deinem Programmierstil liegen. Und runtergemacht wurdest nicht. Es wurde nur konstruktive Kritik geübt.

Aber was ich nicht verstehe, was hat ein Hook mit dem nicht reagieren der Anwendung zu tun? Und wozu soll der Hook letztendlich gut sein? Wenn deine Anwendung mit der Berechnung der Weltherrschaft zu tun hat, wird sie auch nicht auf Nachrichten von dem Hook reagieren können. Also was versprichst du dir von dem Hook?

[EWeiss]

Zitat:

Du aber anscheinend auch nicht.

Dummer Spruch oder? (Zurück in die Kinderstube)
Hast du schon mal eine Fehlerfreie Anwendung geschrieben ?
Denke mal nicht.

Ansonsten würde ich dir den Nobelpreis verleihen.

Um so weiter eine Anwendung fortschreitet um so eher schleichen sich Fehler ein das ist nun mal so.
Aber was schreibe ich noch.

Zitat:

Also was versprichst du dir von dem Hook?

Lesen bildet
Habe es doch schon beschrieben das ich ohne, zuerst den Focus auf meine Tasten des Pianos setzen muss
indem ich sie vorher anklicke.
Mit Hook ist das nicht nötig da sind sie sofort aktiv und können verwendet werden.

Zitat:

Es wurde nur konstruktive Kritik geübt.

Sage es nochmal was ist Konstruktiv?
Nur wenn man sich an die Normen von Delphi hält und ansonsten alles andere vergessen soll ?
Ich brauche keine Tausend Records, Classen und sonst was es geht auch ohne.

PS:
Aber Kopf hoch
Habe das problem bereits gefunden
Wenn du wissen möchtest was es war..

Da dieser Schalter

Delphi-Quellcode:

    WM_LBUTTONUP:
    begin
      if not (SKAERO_GetCheckButtonStatus(SKAERO_GetMainItem(MainHandle, ID_USEKEY)) =
        True) then

immer true ist wenn der Checkbutton aktiv ist habe ich mich quasi selbst
aus WM_LBUTTONUP ausgesperrt.
Andere Messagen wurden daher nicht weitergeleitet. (Geblockt)

gruss