Further proof that VkKeyScanEx sucks

The question that made its way to me through a bunch of others went something like this (product names removed for obvious reasons):

In ######, we use VkKeyScanEx() windows function which can take a Unicode character and return the keystrokes necessary to input that character (eg ctrl, alt, or shift) One of the options it returns is Hankaku key. In ###### we need to simulate all of the keystrokes, but the problem is that we currently ignore Hankaku key, which is the reason for a bug. I was wondering whether you know what is this Hankaku key and more specifically what is Hankaku’s vk keycode.

Thanx in advance,

Regular readers here might recall both Use of VkKeyScanEx and What the %$#!* is wrong with VkKeyScan[Ex]?, and thus they may already know the general problem here, which is that both VkKeyScan and VkKeyScanEx suck. Hugely.

As the other posts have pointed out, they do not handle dead keys. Or ligatures. Or SCGAPS. Or additional shift states, either. These many facts make the functions useless for the majority of the keyboards that ship in the Windows box, all things told.

Beyond that, the details of this particular question are interesting because although IMEs (Input Method Editors) make use of keyboards, the methods by which they use them tend to make all of the various keyboard input functions less useful since both IMM and TSF based IMEs tend to interfere with the usual input flow from keyboards in ways that make all of the functions less useful overall when trying to get information, unless you work out exactly what is and is not going to work.

I inquired further about what was the character that they were passing to VkKeyScanEx, what was being returned, and the reply back was that they were passing ｶ (U+ff76, a.k.a. HALFWIDTH KATAKANA LETTER KA) and (HKL)0x0411 for the HKL (the latter is technically not a valid HKL, but I will talk more about why this can be a problem another time).

The call was returning 0x0854 -- where the 0x08 portion would refer to the shift state (per the docs that would be the Hankaku state), and the 0x54 portion would refer to the virtual key (VK) value -- in this case VK_T.

Now if you look at the Japanese Keyboard Layout, by default it shows か (U+304b, a.k.a. HIRAGANA LETTER KA) on that key:

So, since we wanted Katakana, we had better shift over to it with that key next to the space bar:

and then look again:

Hmmmm.... now we have カ (U+30ab, a.k.a. KATAKANA LETTER KA). I guess we need to shift that too, with the character between the Kana key and the right Ctrl key:

and look one more time:

Ah, there it is! Good old  ｶ (U+ff76, a.k.a. HALFWIDTH KATAKANA LETTER KA).

Now we see the problem -- it actually requires two different keystroke changes in state, both of which act as toggle keys like CAPS LOCK rather than shifting keys like SHIFT/CTRL/ALT. And there is no specific way that either VkKeyScan and VkKeyScanEx has of handling both of them (though note the incorrect try based on putting the other shift state in to capture the two toggle states that kind of confuses the matter. Especially since like several other of the additional keys on the Japanese keyboard (like that extra one in the top row that has a ¥ in it) have no VK (virtual key) values defined and documented.

Which is the final nail on the coffin for using VkKeyScanEx to try get the right answer here....

This post brought to you by ｶ (U+ff76, a.k.a. HALFWIDTH KATAKANA LETTER KA)