Flirting with a strange keyboard, will you remember its language in the morning?

by Michael S. Kaplan, published on 2007/03/26 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/26/1950492.aspx

If you use the GetKeyNameText function, you can get the name of a key -- like the name that you might want to put on a soft keyboard (assuming you did not want to change what was on the key when you changed shift states or something -- the static nature of this function's behavior within the framework of dynamic keyboard layout selection is unavoidable with GetKeyNameText).

Okay, the expository text above about GetKeyNameText that is designed to make the function look stupid and inadequate to the task. Unworthy of your fine application. :-)

Of course, judge not yet lest ye be judged, as they say; it takes just one reminder of when The T's are crossed, but not all of the I's are dotted... to remind us that if we get to smug about what we choose to call stupid (where a "wrong" solution will actually be correct more often than the right one), we can look pretty stupid ourselves without working up a sweat.

Besides, there is one case where GetKeyNameText is actually pretty good at what it does -- in looking at the entirely static buttons like the control keys and the shift keys and such. Maybe it is just that there is no other way to do it, but suddenly in our drunken stupor of frustration our beer goggles notice GetKeyNameText and realize that there is more to this fine function than we first thought....

Not convinced that you want to take GetKeyNameText home yet?

Well, I'll tell you a secret about this little function -- the key names are actually localized....

Because what the French call RET.ARR and the Finns call ASKELPALUTIN and the Swedes call BACKSTEG and the Danes call TILBAGE at the same time as the Americans call it Backspace may just be a "you say po-tay-to, I say poh-tah-to" issue to some, but to others it is a significant issue to get wrong. In a bad way.

Of course, they are not localized the same way that most of Windows is localized.

(If there is anything I have learned about keyboards over the last few years, it is that keyboards always have to be different!)

What is different here is not the most impressive sort of issue; it is that the names are actually stored right in the keyboard layout DLL.

Thus the names that are returned by GetKeyNameText are firmly connected to the layout choice based on the KLID (keyboard layout identifier) which does not in any way need to be tied to the user interface language or even the input language (HKL).

This can actually lead to problems anytime a keyboard layout DLL is reused for multiple, different languages. Which can lead to problems like this one reported on the MSDN Product Feedback Center (it happens due to the fact that Catalan uses the Spanish keyboard layout DLL, a fact that would not matter at all if not for this issue).

Workarounds? Well, you can't just use MSKLC, since those key names are not exposed via the tool. But you can edit the names in the .KLC file directly, as long as you remember to put any name that contains a space in quotes first. You can then load the file in MSKLC, build it, save it, whatever you want to do....

This is obviously not the best or most scalable of all possible models, so people can give some thought to what we might do in the future. One thing to keep in mind -- this is a problem where the first few solutions that occur to us may actually be the wrong answer, too.

Now the only thing you have to remember the morning after is what the keyboard layout DLL's language was, since the DLL may not be able to tell us. If that notion cares you then don't take strange functions like GetKeyNameText home at night....

This post brought to you by ¿ (U+00bf, a.k.a. INVERTED QUESTION MARK)

Satchmo on 9 Aug 2010 2:15 AM:

Michael S. Kaplan on 10 Aug 2010 7:23 AM:

referenced by

go to newer or older post, or back to index or month or day