Thanks Cranky, I've updated the original post to use GetAsyncKeyState.

Can you tell me which languages (or just one) and which keys you know to be broken with GetKeyNameText so I could try it ?
Are we talking about letters not having names or things like Backspace, Page up... ?

German is really bad with GetKeyNameText, for instance "Numpad *" and "Numpad /" keys both return as "(ZEHNERTASTATUR)" which means "(NUMPAD)" (no sign of the button that was actually pressed). Then the formatting isn't consistent, like letter keys are all in caps ie "A" but umlauts are lowercase like "ü".

Another issue with GetKeyNameText is, the strings aren't localized the way you would expect. The language the strings are returned in is tied to the language that is associated with the keyboard layout (since the strings actually come out of the keyboard layout dll), NOT the system language. For instance I have a german installation of windows, but if I switch to the US keyboard layout, the strings returned by GetKeyNameText will be in english.

Thanks.

Cranky
Another issue with GetKeyNameText is, the strings aren't localized the way you would expect. The language the strings are returned in is tied to the language that is associated with the keyboard layout (since the strings actually come out of the keyboard layout dll), NOT the system language. For instance I have a german installation of windows, but if I switch to the US keyboard layout, the strings returned by GetKeyNameText will be in english.

That's the behavior I want. Maybe I should rephrase that in the main post. The idea is that a game or application should display the character (or string describing the key) of the current keyboard layout, which often correspond to the "hardware layout". If the user changed the layout, he/she should see the names for the new layout.

As for the strings being bad in some languages, maybe we could find (or create) a list of similar strings in all languages (I'm thinking of Linux since those would probably be open source) and create a small function that would find the keyboard layout to be able to return the corresponding string.

Sir, you clearly care about your craft. This was the most comprehensive analysis of scan codes I've ever found, and was the only one that went into the arcane specifics of the mysterious "Print Screen" key, which I STILL cannot simulate a key press of using SendInput - but found a workaround for my purposes that didn't require pressing the Print Screen key.

Still, in amongst all the advice telling me to use Virtual Key codes, in spite of stating multiple times that I can't because they are ignored by DirectInput software, this was the only thing I read that gave some insight into why Print Screen was the only key that couldn't be simulated when all the others can.

The kind of research and experimentation on display in this post is exemplary. You should make it a blog post or something.

Thanks, I'm glad it helped you. The article has been added in the handmade.network wiki, you can find it here.

Not to resurrect again, but thanks for this! Nice to see a handmade post as the first result in the google search :)