507 posts
Possibly handling keyboards a bit better
After seeing Jon's rant on keyboard handling and the article he linked, I thought I'd look into ditching the black box that is TranslateMessage.

From looking around on msdn it turns out it's possible but not entirely.

First clue I got was TranslateAccelerator which is the "proper" method of doing shortcut keys. This translates keypresses into WM_COMMAND message and dispatches them. But the interesting part is how you should use it:

if(!TranslateAccelerator(wind, accelTable,&msg){

This is to avoid sending the WM_CHAR when it's been handled. That tells me it's acceptable to not call TranslateMessage.

Looking further into keyboard handling I found the general article with the list of keyboard related functions.

One of them is ToUnicodeEx which does the translation from virtual key and scan code to unicode without sending the WM_CHAR messages. It also affects the kernel state related to stored dead-keys for diacritic. I haven't found a way to sandbox that yet.

So as a possible solution for keyboard handling you could skip TranslateMessage and send just the key presses to the application/custom layer then if it's not consumed by a command pass it through ToUnicode in the platform layer via callback to translate into a set of unicode code points to insert.

Allen Webster
474 posts / 5 projects
Possibly handling keyboards a bit better
Neat, I'll try this out the next time I end up experimenting with the keyboard input stuff.