by Michael S. Kaplan, published on 2010/06/08, original URI: http://blogs.msdn.com/b/michkap/archive/2010/06/08/10017386.aspx
The title is an allusion to one of the only Hardy Boys novels I was able to get into growing up (this one), especially the original version which is the one I read first. There is neither literal nor symbolic connection between the books and this blog, though the differences between the two versions might be an interesting future blog....
Rob's question was direct and to the point:
[Our product] uses a keyboard filter to ensure that input from specific keyboards goes only to specific sessions running on the machine. We recently discovered that the Korean keyboard’s Han/Eng (VK_HANGUL) key does not work.
We’re getting a scan code of 0x0072 from the driver. This eventually gets passed to MapVirtualKeyEx (scancode, MAPVK_VSC_TO_VK[_EX], hklKorean), which fails to convert to a VK.
Working the other way to see what MVKE expected, it returns a scan code of 0xE038 for VK_HANGUL. This seems weird because 1) it’s not what the keyboard actually sends, and 2) it’s identical to VK_RMENU (which unsurprisingly does not map to a scan code if using a Korean layout).
Our standard method of feeding raw scan codes to MKVE to convert to virtual keys works for everything else, so I wondered if anyone could shed some light on why VK_HANGUL is special, and how raw input thread is able to map/translate this scancode into something that MVKE is willing to convert.
Thanks,
Rob
Now it's a funny thing about keys like that Han/Eng key.
By which I mean this key:
The funny thing?
That they aren't a part of the keyboard layout DLL mapping, the one that exists between scan code values and virtual key values.
There is another very well known key that behaves somewhat like this.
One that I discussed years ago in In case you have a yen to extend your keyboard (or at least want a yen?).
This key:
Yep, that old Yen key.
Now the two cases are not completely analogous (one is a modifier key, the other one that contains a character), but in both cases the results are completely IME moderated and thus you cannot use the keyboarding functions in USER32.DLL to interrogate the HKL for information.
Now let's say you wanted (rather than creating a keyboard layout that made use of a key, as was the case in that older blog) to work with the existing keyboards as they are.
Believe it or not, the answer is very simple -- you have to hard code the scan code value and do the special operation you want to with it.
This may urk you, it urks me as well.
Though if you stop and think about it, are the IMEs doing anything better here?
The Input Method Editors are essentially doing the same thing in this case -- hard coding these specific keys to get their work done.
And we know this because the sophisticated functions used to interrogate keyboard layouts do not return the information in question, the information that they return for pretty much every other key on the keyboard....
Now of course this leaves one final bit of mess in the case of VK_HANGUL: the fact that trying to map it to a scan code returns a value (and the wrong value, at that!). this part seems to me like kind of a bug, like someone hitting the end of a table and returning the last value in the table, even though it is technically wrong.
But fixing it now after it has behaved that way for over a decade, for the sake of a key that won't work unless it is used by every IME that doesn't depend on a working mapping?
Trying to get that bug addressed would definitely be an uphill battle!