Names for Japanese special keys

[lexikos]

If anyone wants the following key names added, I am just waiting for answers to some questions.

Code: Select all

+// Special keys in Japanese keyboard
 +, {_T("Muhenkan"), VK_NONCONVERT}
 +, {_T("Henkan"), VK_CONVERT }
 +, {_T("KanaHira"), VK_OEM_COPY }
 +, {_T("HanZen1"), VK_OEM_AUTO } 
 +, {_T("HanZen2"), VK_OEM_ENLW }

VK_OEM_AUTO and VK_OEM_ENLW are emitted by a same key interchangeably in windows. It swaps Japanese input mode and English input mode.

Do you mean alternately (i.e. after each press the keycode swaps)? Does one keycode switch to "Hankaku" mode and the other switch to "Zenkaku" mode? If that's the case, wouldn't it be better to use the more meaningful names to distinguish between the two rather than "1" and "2"? Similarly, Numpad1 and NumpadEnd are the same key but named according to the effect of the keycode.

https://github.com/Lexikos/AutoHotkey_L/pull/55

[A_User]

I happened to have a Japanese keyboard, a type of 109 keyboard.

Does one keycode switch to "Hankaku" mode and the other switch to "Zenkaku" mode?

That's right. They share the same physical key and it toggles the mode. Zenkaku means full width and Hankaku means half width.

When typing Japanese words, one has to use input software such as Microsoft IME bundled with Windows installation. There are other ones besides Microsoft IME such as Google IME, ATOK, and Baidu IME etc. And it seems the sent virtual key codes differ depending on the software. I checked only with Microsoft IME and Google IME so the number of samples may be too few to determine the behavior.

I used the InputKey() funciton (https://autohotkey.com/board/topic/8059 ... -keypress/) to check which virtual key code is sent when pressing it.

Microsoft IME has the following five input modes which the user has to select when typing. (a) and (e) are mostly used and other modes are occasional.
a) Hiragana
b) Zenkaku Katakana
c) Zenkaku Eisu
d) Hankaku Katakana
e) Hankaku Eisu

Google IME has the following six modes. (a) and (f) are mostly used and others are occasinal.
a) Hiragana
b) Full-width Katakana
c) Full-width Alphanumric
d) Half-width Katakana
e) Half-width Alphanumeric
f) Direct Input

I see different results by pressing the Zenkaku/Hankaku key:

1. 0xF4 - when none of the input software is selected in the language bar.
2. 0xF0 - when Microsoft IME is selected and the input mode is Hiragana, Zenkaku Katakana, Zenkaku Eisuu, or Hankaku Katakana
3. 0x1B - when Microsoft IME is selected and the input mode is Hankaku Eisu
4. 0xC0 - when Google IME is selected in the language bar, regardless of which input mode is selected

If that's the case, wouldn't it be better to use the more meaningful names to distinguish between the two rather than "1" and "2"?

I agree. Naming them should be more careful. Once it is published, it becomes hard to change.

[lexikos]

It seems more complicated than I thought. With the key varying that much, I'm inclined to leave it unnamed (and let users continue to rely on VK or SC).

What the conditions are before pressing the key does not tell me what meaning or effect the VK code has.

[lexikos]

I just accidentally discovered that pressing CapsLock with the Microsoft IME in Windows 10 (and default settings) toggles the mode and does not generate a normal CapsLock keydown/up. (I only have the IME installed for the purpose of testing AutoHotkey, and happened to be testing a script that uses CapsLock to switch languages.)

I currently have the hardware keyboard layout set to "Japanese keyboard (106/109) key", but my actual keyboard is an ordinary US keyboard. (Changing the setting requires a reboot.)

If I press CapsLock ...

• while the Hiragana mode is active, it generates vkF2 up and vkF0 down, with sc03A (same SC as normal CapsLock).
• while a Katakana mode is active, it generates vkF1 up and vkF0 down, with sc03A.
• while an alphanumeric mode is active, it generates either vkF0 down or nothing at all, depending on whether I've typed anything (since switching modes?).

In all cases, pressing CapsLock (or the button on the taskbar) toggles between Half-width Alphanumeric/Direct Input and the last used mode. No keyboard events are generated by releasing CapsLock or switching to any of the modes via the taskbar.

I'd guess that vkF0, vkF1 and vkF2 key-down events are generated by the system upon entering the corresponding mode via the keyboard, and key-up events are generated upon leaving that mode. This makes detecting mode switches via keyboard fairly trivial, but means that they really do not act like keys, which is one more reason not to add key names.

vkF2 corresponds to KanaHira in the pull request, but it was noted that the dedicated KanaHira key has scan code 0x70.

[lexikos]

I came across these constants in the Windows DDK that seem relevant (at least, the first three match the modes of the Japanese layout I was testing):

Code: Select all

#if (NTDDI_VERSION >= NTDDI_WINXP)
#define VK_DBE_ALPHANUMERIC              0x0f0
#define VK_DBE_KATAKANA                  0x0f1
#define VK_DBE_HIRAGANA                  0x0f2
#define VK_DBE_SBCSCHAR                  0x0f3
#define VK_DBE_DBCSCHAR                  0x0f4
#define VK_DBE_ROMAN                     0x0f5
#define VK_DBE_NOROMAN                   0x0f6
#define VK_DBE_ENTERWORDREGISTERMODE     0x0f7
#define VK_DBE_ENTERIMECONFIGMODE        0x0f8
#define VK_DBE_FLUSHSTRING               0x0f9
#define VK_DBE_CODEINPUT                 0x0fa
#define VK_DBE_NOCODEINPUT               0x0fb
#define VK_DBE_DETERMINESTRING           0x0fc
#define VK_DBE_ENTERDLGCONVERSIONMODE    0x0fd

#endif

[SOTE]

I think this is all pretty good stuff, but I'm curious on why the focus on Japanese? The AutoHotkey website doesn't even have a Japanese subforum. Speaking of which, not sure why that is so. Why not greater focus on say Chinese? There is a Chinese subforum.

Why is this such a problem for those using Japanese, that it needs special attention, but not those using say Chinese or Korean?

[lexikos]

This is about the pull request that I referenced in my first post, and nothing more.

Today, I was reading through kbd.h for a completely unrelated reason.

[lexikos]

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).