by Michael S. Kaplan, published on 2005/07/18 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/07/18/439870.aspx
On the microsoft.public.win32.programmer.international, Nick asked:
Does anyone know why this function returns -1 when it is used to convert the
character code of a "dead key" when the keyboard layout is set to German on
an English Windows.
For example, when I tried to convert '´' (acute, whose charater code is
0xb4) like this:
It returns -1.
Hmmm.... two part answer here, Nick. :-)
First, the dead key value is not 0xb4 (a.k.a. in Unicode U+00b4, ACUTE ACCENT) -- that is the spacing version of the character, and dead keys are actually the combining form, generally. So a good reason for VkKeyScanEx to return -1 is that the character for which you are requesting a VK value does not actually exist on the keyboard.
Keyboards on all of the NT-based platforms are indeed Unicode-based. They will have characters to converted to the default system code page, but when a character does not exist (as in the case of spacing diacritic forms, a lot of the time), then a best fit mapping will happen.
However (and this gets us to part two of the answer!), VkKeyScanEx returns only simple VK mapping values, not complex ones such as dead keys in a lot of these cases. So even if you pick the right character value (in this case U+0301, a.k.a. COMBINING ACUTE ACCENT), you will still not get a return value here in such cases.
You see similar behavior with the ToUnicodeEx function. If you pass a VK value that returns a dead key, then the function will return -1, even though in this case the buffer will contain the dead key in question. It will also be in one of those odd states with a dead key in the input buffer, waiting on the next call to see what you will be adding to it. That -1 kind of signals the situation for you.
This post brought to you by " ́" (U+030a, a.k.a. COMBINING ACUTE ACCENT)
go to newer or older post, or back to index or month or day