[Win32] Unterschiedliche Scan Codes

  • C++

Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von rwCapt.

    [Win32] Unterschiedliche Scan Codes

    Guten Abend,

    ich arbeite aktuell in der WndProc und möchte beim Abhandeln der Message WM_CHAR einen Abgleich zwischen dem Scan Code machen, der aus dem 16. bis 23. Bit von lParam extrahierbar ist und der Funktion OemKeyScan, die im low-order-word ebenfalls den Scan Code des über wParam gelieferten characters ausgibt. Dann noch kombiniert mit der Funktion IsCharAlphaNumeric ist mein Ziel zu ermitteln, ob es sich bei dem input character um ein schreibbares/darstellbares Zeichen handelt. Nochmals kombiniert sind die beiden Abfragen mit der Prüfung, ob der character code (aus wParam) größer gleich 32 ist. Folgendes Statement ergibt sich daraus (das Downcasting von wParam ist nicht berücksichtigt, wird aber gemacht):

    C-Quellcode

    1. if (wParam >= 32 && (scanCode == LOWORD(OemKeyScan(wParam)) || IsCharAlphaNumericW(wParam))) // scanCode ist aus lParam extrahiert (16. bis 32. Bit)


    Ziel des ganzen ist es, jenen Tastendruck wie die Entf./DEL-Taste herauszufiltern, der komischerweise den gleichen Virtual Key Code (das was wParam liefert) wie der L'.' Punkt-Character hat. Ich könnte selbstverständlich ermitteln, ob es sich denn nicht explizit um jene Entf.-Taste handelt, nur weiß ich nicht, ob es nicht noch mehrere solcher bisher von mir unentdeckten Tasten gibt, die die gleichen Virtual Key Codes haben wie irgendein Virtual Key Code über 32, von denen ich bisher angenommen hatte, dass sie lupenrein Zeichen repräsentieren, die wirklich darstellbar bzw. dafür da sind, ein Zeichen darzustellen. So wie ich das bisher gesehen habe, lässt sich mit dem eben gezeigten conditional statement relativ gut ermitteln, ob der Virtual Key Code, der durch wParam übergeben wird, ein Zeichen ist.
    Nur bei den ALT codes schlägt die if-Abfrage fehl. Da stimmen weder der Return aus OemKeyScan mit dem aus lParam extrahierten scanCode überein, noch gibt mir IsCharAlphaNumeric ein true aus. Ich müsste irgendwie herausfinden, ob es sich um einen ALT code gehandelt hat, der immer zum Ziel hat, ein darstellbares Zeichen irgendwo hineinzuschreiben. Ich sehe gerade, dass das 30. Bit aus lParam in der Message WM_CHAR den vorherigen key state anzeigt (gedrückt oder gelöst). Bei Tastendrücken über einen von der Tastatur zeigt das 30. Bit eine 0 und bei ALT codes eine 1. Damit könnte man das schon mal auseinanderhalten. Ich würde meine Frage dann doch mal dahingehend ändern, ob es eine bessere Methode gibt, um wirklich nur Zeichen (also auch Zahlen) durch den Filter zu lassen.

    Ich danke schon mal vorab!

    Edit: Die Lösung ist doch einfacher als gedacht. Es reicht aus, die letzte Window-Message und den letzten Tastendruck (in WM_KEYUP) zu tracken und dann in WM_CHAR zu prüfen, ob die letzte Message WM_KEYUP und der letzte Tastendruck VK_MENU (ALT-Taste) waren. Wird die ALT-Taste anderweitig gedrückt, also nicht um ein Zeichen einzugeben, wird WM_CHAR gar nicht aufgerufen. In dem Falle ändert sich die getrackte lastMessage ja auch sofort wieder und dann wird jene Abfrage in WM_CHAR ja auch false sein.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „rwCapt“ ()

    @rwCapt Es gibt da noch die Prozedsur GetAsyncKeyState().
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Oder, noch besser, GetKeyState(). Naja, eine unnötige Frage wieder mehr gestellt. Manchmal fehlt einem nur ein Gedankengang zum Ziel.
    Mit GetKeyState filtere ich also jetzt die CTRL Taste raus, damit in der Message WM_KEYDOWN, die in meinem Falle WM_CHAR vorzuziehen ist, solche Tastenkombinationen nicht als Character erkannt werden.
    ALT Codes wiederum triggern nur die Message WM_CHAR und WM_KEYDOWN gar nicht.