Die Unsitte Tastatureingaben mit WM_KEYDOWN Nachrichten zu simulieren

Dies ist eine Ergänzung zu meinem Blog Eintrag Die Unsitte Windows interne Nachrichten zu versenden.
In einem der Kommentare wurde ich gefragt wie man es nun mit WM_KEY… Nachrichten richtig macht, weil ich auch diese Nachrichten als „intern“ definiert habe. In meinen Augen ist es unzulässig WM_KEY… Nachrichten per PostMessage oder SendMessage zu versenden. Also ist die Frage berechtigt:
Wie macht man es richtig, mit der Simulation von Tastatureingaben für andere Prozesse ❓

Ersteinmal möchte ich erklären, warum das Senden einer WM_KEY… Nachricht nicht funktioniert, oder oft genug nicht richtig funktioniert:

  1. Alleine wenn das Programm GetKeyState oder GetAsynchKeystate benutzt um zu ermitteln ob gleichzeitig sie Strg- oder die Umschalttaste gedrückt wird, dann funktioniert SendMessage/PostMessage nicht mehr.
  2. Wenn das fremde Programm Accelerator verwendet, dann wird hier auch durch senden einer WM_KEY… Nachricht der Accelerator oft genug nicht ausgelöst. Die Folge: Der gewünschte Effekt bleibt aus.
  3. Man bekommt schnell Probleme mit synthetisierten Zeichen, die zwei Tasteneingaben erfordern, z.B. ^ und a, für â.
  4. Man muss fürchterlich darauf achten, wenn ein Befehl den Fokus wechselt.
  5. Die Applikation hat nicht den Fokus! Alleine das kann schon Fehlverhalten auslösen, denn normalerweise kann nur eine aktive Applikation mit Fokus Tastatur- und Mauseingaben erhalten.
  6. WM_SYSKEY… Nachrichten werden nicht korrekt erzeugt.

Wie macht man es nun ❓  
Es ist ganz einfach: Man benutzt SendInput ❗  
Der Vollständigkeit halber sei hier noch die legacy Funktion keybd_event erwähnt.

SendInput reiht die Eingaben ein in die Eingabequeue für das gesamte Windows System ein und liefert diese an die aktive Applikation aus und an das Fenster, das den aktuellen Eingabefokus hat. Man kann also nicht einfach so auch das Zielfenster angeben, dass die Eingaben erhalten soll. Das merkt man schon daran, dass es kein Fensterhandle gibt, dass man als Ziel angeben könnte für SendInput.

Frage aber nun: Wie gewährleistet man, dass das richtige Programm die Tastaturnachricht bekommt  ❓

Auch hier ist die Antwort relativ einfach! Zwei Dinge sind dazu nötig:

  1. Dass Zielfenster, bzw. den Thread in dem das Zielfenster muss ausgewählt werden, damit er diese Eingaben auch erhalten darf. Das wird durch AttachThreadInput erreicht. Denn wir wollen die Daten ja nicht an unsere Applikation senden. ❗ Bitte hinterher nicht vergessen AttatchThreadInput mit FALSE aufzurufen und den Thread wieder zu detachen.
  2. Man muss den Fokus korrekt setzten für das Fenster, dass die Eingaben erhalten soll!
    Ist der Zielthread jetzt an die Eingabequeue angeschlossen, kann man ohne Probleme SetFocus ausführen (was ohne AttachThreadInput normalerweise auch nicht möglich wäre).
  3. Wird jetzt SendInput ausgeführt, werden alle Nachrichten korrekt erzeugt und auch alle Commands entsprechend der Tastaturfolge ausgelöst. Auch spezielle Umlaute und Unicode Zeichne lassen sich so erzeugen.

Es ist gar nicht so schwer es richtig zu machen. :mrgreen:

10 Gedanken zu „Die Unsitte Tastatureingaben mit WM_KEYDOWN Nachrichten zu simulieren“

  1. Wenn ich mich nicht ganz und gar irre kann ist ein minimiertes Fenster unsichtbar und kann per Definition weder den Focus haben und auch keine Tastatureingaben erhalten und schon gar kein Childwindow innerhalb der Applikation, die minimiert ist. Das ist so…
    Man mag mit WM_KEY… Nachrichten Effekte erzielen, jedoch wird man niemals gleiches Verhalten erreichen wie bei einer echten Tastatureingabe bzw. einer die durch SendInput erzeugt wurde.

  2. Hi Martin,

    ich habe die beiden Beiträge zu diesem Thema mit großem Interesse gelesen, verstehe jedoch eine Sache nicht. Du sagst, ein Fenster empfängt keine Nachrichten, wenn es nicht den Fokus hat. Wenn ich allerdings ein Fenster per Spy++ überwache, empfängt es doch verschiedene Nachrichten (z.B. WM_NCHITTEST, WM_SETCURSOR). Also, was verstehe ich denn jetzt falsch?

  3. Hmpfh! Logisch. Dann fass ich mir jetzt mal an den Kopf und überprüfe dort alles auf Vollständigkeit. Und morgen gehe ich zum Optiker…

  4. Hallo Martin,

    ich habe eine Frage zu SendInput! Löst der Aufruf der Funktion auch das erste Problem, das du beschreibst, mit GetKeyState und GetAsyncKeyState?

    Ich möchte nämlich Tastatureingaben bei einem Programm simulieren, das zur Abfrage scheinbar nur GetAsyncKeyState benutzt. (Böse, böse, ich weiß, ist aber nicht von mir erstellt, kann es folglich auch nicht ändern)

    Auf SendInput reagiert das nicht, auch mit keybd_event habe ich es erfolglos versucht.
    Weißt du, ob es überhaupt möglich ist, einem solchen Programm Tastatureingaben vorzutäuschen, oder irgendwie die Rückgabewerte von GetAsyncKeyState zu manipulieren?

  5. Gute Frage. Ehrlich gesagt, habe ich mir um GetAsynchKeyState und SendInput noch nie recht Gedanken gemacht… IMHO müsste GetAsncKeyState auch auf SendInput reagieren, aber ich mag mich irren.
    Hier ist ja auch schon ein Konflikt, denn SendInput erzeugt einen Queue Eintrag, während ja GetAsyncKeyState den „echten“ KeyState angibt…

    Ich müsste das mal testen.

  6. Nun ja, SendMessage wirkt auf mich beruhigender, da es ein
    Fensterhandle „hwnd“ mit als Argument hat, womit ich also „dem“ Fenster
    und nicht „irgendeinem“ Fenster unsere Nachricht senden kann. Man
    denke an einen Dialog mit Button’s, Static’s und vielleicht mehreren
    Edit’s. Will man letztere auffuellen, trifft man per „hwnd“ ins richtige
    Fenster. GetKeyState() wuerde ich vermeiden. Vielleicht ist auf einem
    stark belasteten PC die Taste gar nicht mehr gedrueckt, bis unser
    Programm endlich an die Stelle mit unserem GetKeyState() kommt. Mit der
    WM_KEYxxx-Nachricht kommen wir auch die SHIFT – und CTRL – Tasten
    als Bits in „lParam“ an.

    1. 1. Du irrst. GetKeyState ist ja genau der an dieser gerade bearbeiteten Nachricht gebundene Status der Tasten. Zu dem Moment als die Nachricht in die Queue kam.
      2. Ob es brühgend auf Dich wirkt oder nicht. Mit SendMessage kann man keine kombinierten Zeichen übergebenund nicht alle Tastenfunktionen auslösen zudem muss kein Programm dies unterstützen, da ja geade GetKeyState nicht synchron ist.
      3. Wo bitte wird in WM_KEYDOWN der Status der Shift und Ctrl Taste übermittelt? Nirgends. Wenn man also prüfen will ob Strg+C gedrückt wurde bleibt einem nur GetKeyState und dann? Kein Entwicklermerkt sich, dass eben die Strg Taste gedrückt wurde um hinter C zu verarbeiten…

Schreibe einen Kommentar zu input sender Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.