The
documentation for KbdEdit reminded me that VK_OEM_3 (
`/
~ on the US layout) also toggles the mode on the Japanese layout. Testing it again, I realized that although it seems to have the same effect as CapsLock, it actually generates different events.
- Usually vkF4 (VK_DBE_DBCSCHAR), vkF3 (VK_DBE_SBCSCHAR) down when entering a half-width mode.
- Usually vkF3 (VK_DBE_SBCSCHAR) up, vkF4 (VK_DBE_DBCSCHAR) down when entering a full-width mode.
- If I change mode with the mouse, the next press of the key generates the wrong events, but subsequent presses are correct.
- Switching between "half-width katakana" and "half-width alphanumeric/direct input" always produces vkF3 up, vkF4 down.
- It also depends on modifier state. If I hold Ctrl, it generates events as though it is toggling between SBCS and DBCS, but actually has no effect (as shown by the taskbar, IME toolbar and character entry).
Like CapsLock, the scan code for the actual key is used (sc029 in this case) and there's nothing on key-release.
It seems this is all dependent on the keyboard layout. The
kbd106 sample refers to sc029 as the "Hankaku/Zenkaku/Kanji key" and sc03A as the "Alphanumeric/CapsLock key". There's also "Hiragana/Katakana/Roman key" (sc070), "Conversion key" (sc079) and "Non-Conversion key" (sc07B).
I also found that the names for these special keys are defined in
kbdjpn.h and mapped to scan codes in the keyboard layout. GetKeyNameText() should return these key names if appropriate for "the current keyboard layout" (which I presume is the active one for the current thread, i.e. the script itself). For example:
Code: Select all
0x70, (LPWSTR)SZ_KEY_NAME_HIRAGANA,
0x79, (LPWSTR)SZ_KEY_NAME_HENKAN,
0x7b, (LPWSTR)SZ_KEY_NAME_MUHENKAN,
I'm not aware of any function for converting key names to scan codes. The names are mapped via scan code, not VK, but it's possible that the same functions (or even the same names) are assigned to different scan codes in different layouts. I suppose that passing the VK_DDE_* codes to MapVirtualKeyEx() should return the appropriate scan codes, which could then be used to distinguish between the actual keys and the mode-switching functions of CapsLock etc.
The actual functions of these keys are mapped via "NLS", with
KbdNlsLayerDescriptor (in the keyboard layout dll) as the starting point, but I haven't fully deciphered the tables. The kbd106 sample shows that holding different modifiers will cause these keys (sc029, sc03A/CapsLock, etc.) to produce different VK codes, and they do, but it seems that my system (probably the Windows 10 Japanese IME in general) ignores the VK.
The base/default scan code to VK mappings are defined as macros in kbd.h in the Windows DDK (which doesn't matter if you're using MapVirtualKey(), but makes it difficult to decipher the keyboard layout samples if you don't have the DDK).