Keyboardstate ist quasi "IsPressed" für alle Tasten gleichzeitig. Um das zu nutzen müsste man extrem oft Abfragen machen und quasi (hier 256) alle Keys andauernd abfragen um zu schauen ob etwas gedrückt wurde. Das ist für ein "paar wenige" Keys ggf eine gute Idee, aber wenn ich ca. 150 mögliche Keys überwachen muss, nur damit ab und zu einer davon gedrückt und erkannt wird, dann sind 99.9% der Abfragen nutzlos^^
Damit auch schnelle Tastendrücke erfasst werden wäre man außerdem gezwungen mit hoher Frequenz zu prüfen (da die Events hier ungepuffert sind).
Ich lass die Idee noch ein bisschen sacken, und dann wirds wahrscheinlich die Version von Oscar (Eigenes Window + Proc) mit sämtlichen Sachen die ich vergessen habe (wovon BugFix einige aufgezeigt hat). Wobei ich noch nicht ganz sicher bin, die WMs (ohne ein eigenes Window) sind auch verlockend, vermutlich weniger Komplexität in der Implementierung, dafür mehr Overhead. Allerdings ist laut der Hilfe WM_CHAR nicht immer nutzbar, wo das vermutlich am einfachsten wäre (auch in Bezug auf das Gedrückthalten von Tasten und Kombinationen von Tasten)...
Da fällt mir direkt eine Frage ein: GUIRegisterMsg hat ja keinen Parameter für hWND. Hat ein Layered-Window dort einen eigenen Zugang (GuiSwitch und dann GUIRegisterMsg? Ich kenne mich damit leider nicht aus...), sodass ich z.B. WM_CHAR im Layered-Window registrieren kann (weil ich ja 100% sicher sein kann, dass ich kein Edit-Ctrl habe, also müsste WM_CHAR verfügbar sein)?
Edit: Ich glaube ich bin da auf dem mentalen Holzweg. Kann es sein, dass die von RegisterMsg registrierten Funktionen mit den via SetWindowLong(..., WNDPROC, ...) registrierten Funktionen auf ein und dasselbe verweisen und diese Methode quasi die oben angesprochene GUIRegisterMsg Version "mit" HWND ist? Falls das so ist glaube ich es jetzt ansatzweise verstanden zu haben...
Mensch, ein simples einfaches Texteingabefeld ist viel zu kompliziert... ![]()
lg
M