[ww-tedit-dev] PeekMessage() is the next step

[petar marinov]

Windows GUI keyboard handling is hard to understand. Apparently we have 
these sequences of messages:
WM_KEYDOWN -> WM_CHAR -> WM_KEYUP (produces ascii and ctrl characters)
WM_SYSKEYDOWN -> WM_SYSCHAR -> WM_SYSKEYUP (produces all Alt combinations)
WM_KEYDOWN -> WM_KEYUP (F1-F10, arrows, Home, End, etc.)

Now, F1 is WM_KEYDOWN but when in Alt combination it is WM_SYSKEYDOWN. 
To me it seems WM_KEYDOWN analisys is necessary, sorf of 
switch(scancode), in order to arrange for immediate enqueue operation or 
to know to wait for WM_CHAR (or WM_SYSCHAR if after WM_SYSKEYDOWN). 
Complex stuff!

One ray of hope was:

--- from MSDN ---
ToAsciiEx Function

The ToAsciiEx function translates the specified virtual-key code and 
keyboard state to the corresponding character or characters. The 
function translates the code using the input language and physical 
keyboard layout identified by the input locale identifier.

Syntax

int ToAsciiEx(

    UINT uVirtKey,
    UINT uScanCode,
    PBYTE lpKeyState,
    LPWORD lpChar,
    UINT uFlags,
    HKL dwhkl
);

....

lpKeyState
    [in] Pointer to a 256-byte array that contains the current keyboard 
state. Each element (byte) in the array contains the state of one key. 
If the high-order bit of a byte is set, the key is down (pressed).

    The low bit, if set, indicates that the key is toggled on. In this 
function, only the toggle bit of the CAPS LOCK key is relevant. The 
toggle state of the NUM LOCK and SCOLL LOCK keys is ignored.

-- end ---

So, all things equal this is better than a state machine approaching 
levels of intelligance to pass a Turing test, but, NUM LOCK is not 
processed, back to the drawing board ... I think my next best hope is 
PeekMessage(). I will peek at the next message after WM_KEYDOWN or 
WM_SYSKEYDOWN and act accordingly.

-petar