[erledigt] Mögliche Ursachen für "falsches" WM_KEYDOWN?

[hustbaer]

Gibt es unter Windows bekannte Gründe warum ein Fenster ein WM_KEYDOWN geschickt bekommen könnte, welches nicht durch das Drücken einer Taste auf einem angeschlossenen Keyboard verursacht wurde?

Also mir ist bekannt dass man das leicht verursachen kann, z.B. indem man selbst PostMessage / SendMessage aufruft oder SendInput bzw. keybd_event verwendet.

Das tut unsere Applikation selbst aber nicht, und mir ist auch nicht bekannt dass wir eine andere Thirdparty Applikation auf dem System hätten die das tun würde.

Trotzdem haben wir ein Problem, und eine der möglichen Ursachen dafür ist wenn das Fenster aus irgend einem Grund ein WM_KEYDOWN mit 'Z' oder 'Y' geschickt bekommen würde.
Unsere Applikation prüft dabei die "flags" nicht, es wäre also auch möglich dass es in Wirklichkeit ein Shift+Z/Y bzw. Ctrl+Z/Y o.ä. ist.

Normalerweise würde ich hier gar nicht weiter nachdenken und das mit einem "das kann nicht sein" abhaken. Da der Zeitpunkt der Fehler allerdings relativ kurz nach der Einführung des Codes der auf 'Z' bzw. 'Y' reagiert reportet wurde, und ich sonst keine Ursache finden kann, dachte ich mir ich frage lieber mal nach.

Mich interessiert jetzt also ob es irgend welche bekannten Programme/Systemteile/Windows-Mechanismen gibt die dafür verantwortlich sein könnten.

[Swordfish]

Was sagt denn Spy++? Kommt in den entsprechenden Situationen ein WM_KEYDOWN ?

[hustbaer]

Das kann ich leider nicht überprüfen, da ich nur einen Bug-Report habe, aber keine Möglichkeit den Fehler nachzustellen.
Im nächsten Release haben wir dazu erweitertes Logging drinnen. Wenn der Fehler dann wieder auftritt und wir Logfiles von einem betroffenen Geräte bekommen, wissen wir mehr. Hoffentlich

Wäre aber natürlich cool wenn ich den Fehler für das nächste Release schon beheben könnte.

[Mr C]

welches nicht durch das Drücken einer Taste auf einem angeschlossenen Keyboard verursacht wurde?

...hört sich sehr stark nach Tastendruck simulation. ))

Mich interessiert jetzt also ob es irgend welche bekannten Programme/Systemteile/Windows-Mechanismen gibt die dafür verantwortlich sein könnten.

GetAsyncKeyState
keybd_event
usw...
System/Progamme ohne zu wissen simulieren tasten druck...klingt sehr verdächtig.
Kann es sein, dass du selber was programmiert hast... )))

[Martin Richter]

So etwas ist mir noch nie unter gekommen.
Ich wüsste auch nur, fremde Programme oder Tastatursimulation anderer Programme.

Hast Du schon mal daran gedacht, dass der Stack "zerstört wird" und aus einer normalem Nachricht eine ganz andere wird...?

[hustbaer]

Martin Richter schrieb:

So etwas ist mir noch nie unter gekommen.
Ich wüsste auch nur, fremde Programme oder Tastatursimulation anderer Programme.

OK, danke.

Martin Richter schrieb:

Hast Du schon mal daran gedacht, dass der Stack "zerstört wird" und aus einer normalem Nachricht eine ganz andere wird...?

Nö.
Ich hoffe doch stark dass das nicht passiert.
Ich denke dann wird es wohl doch an etwas anderem liegen - ist ja wie gesagt nur eine der möglichen Ursachen.

[Swordfish]

Wenn ich Dich recht verstehe dann ist das Programm irgendwann in einem Zustand, in dem ein WM_KEYDOWN mit 'z' oder 'y' weder erwartet noch erwünscht ist. Kann das Programm dann nicht aufgrund seines Zustandes solche Messages einfach ignorieren? Dann wäre zumindest diese potentielle Fehlerquelle im nächsten Release ausgeschlossen.

[Martin Richter]

Ich tippe mal eher das ein Undo oder Redo passiert den, der User nicht ausgelöst hat und damit Daten verändert werden.

[hustbaer]

'Y' bzw. 'Z' löst aus dass ein bestimmter Vorgang gestartet wird der das Gerät für bis zu einer Minute blockiert - da werden z.B. Temp-Tables upgedated die zum Betrieb notwendig sind.
Dass man das über's Drücken einer Taste auslösen kann wurde nur eingebaut damit wir diesen Vorgang besser testen können.
Prudiction-Systeme laufen ohne Keyboard, so dass das kein Thema sein sollte.

Aber wie gesagt: ich bin mittlerweile wieder von der Idee abgekommen dass ein WM_KEYDOWN verantwortlich sein könnte.

[hustbaer]

Ist zwar nicht [erledigt] in dem Sinn dass ich die Ursache gefunden hätte, aber ich gehe jetzt mittlerweile davon aus dass die Ursache doch kein WM_KEYDOWN ist. Der Threads als solches kann also als erledigt angesehen werden.