In any case, if you end up testing the approach, I’d be grateful to learn how it went.

Also, this is a simple way that seems to work for me when trying to get the information of WM_KEYDOWN and WM_CHAR together:

BOOL MyTranslateMessage(const MSG* message)
{
if (!TranslateMessage(message))
return FALSE;

MSG translated_message;
BOOL has_translated_message =PeekMessage(&translated_message, message->hwnd, WM_KEYFIRST, WM_KEYLAST, PM_REMOVE);

if (has_translated_message)
{
//Do stuff with the data of the translated message and the original message
}
else
{
//Do stuff with the message
}

}

I cannot guarantee this to be entirely flawless since I’ve only been using it for testing purposes, but logically, you generate one message with TranslateMessage that you retrieve and remove directly with PeekMessage, so unless something else posts WM_CHAR messages to your message queue, you should be fine.

I have also noticed that you can trap the delete key as wParam = 46 in a WM_KEYDOWN message.
I have used this to stop users using the delete key in certain fields.

Thanks!

You mention that the concept of a keypress is lost, because WM_KEYDOWN and WM_CHAR are completely unrelated. However, at least according to MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/aboutkeyboardinput.asp) - I know you don’t think highly of MSDN - WM_KEYDOWN messages contain a “previous key-state flag” in their lParam value. If this flag is 1, the WM_KEYDOWN message is a result of the autorepeat functionality. Further down on the same page they say, “The contents of the lParam parameter of a character message are identical to the contents of the lParam parameter of the key-down message that was translated to produce the character message.”
So it should be possible to recognize keypress events by examining vanilla WM_KEYDOWN or cooked WM_CHAR events. Am I missing something?