In case you have a yen to extend your keyboard (or at least want a yen?)

It was last week in the post Variation on that theme of wanting more keys covered by MSKLC that I talked about Olivier's non-specific question about adding additional keys to the keyboard with MSKLC.

And then yesterday, Olivier gave the specifics in a comment:

In my specific case, I was talking about an Apple Japanese keyboard that has 3 keys not present in default layout:

- Yen key (left to delete key)
-  2 keys, one to left and one to right of space bar (used to switch input method)

Under Windows, these keys currrently don't work.

Hope this helps.

Olivier

So now that he gave some specifics, I thought I would dig in a bit. :-)

For this post, I am going to focus on that Yen key that Olivier mentioned (the same key he refers to on the Japanese Apple keyboard exists on the Windows 106 key Japanese keyboard). Here is a picture of the one I have, just so we know what we are talking about:

Now you can compare this to the keyboard you find up on GlobalDev:

Hmmm.... that key does not really seem to be very well represented, does it? It definitely isn't that other key under the backspace, either.

And even though MSKLC has a Japanese keyboard on the list of existing keyboards, that one doesn't have this key either. Which is why MSKLC doesn't have this key, by the way -- because no existing keyboard ever maps the scan code. EVER.

So let's see if we can do something here about this, okay? :-)

We'll take that little app I wrote in Handling [Unicode] input in the console and use it with that Japanese keyboard to see what this key outputs:

E:\test\READ\Debug>read
ReadConsoleInput test
Ctrl-D to quit.

#      UC    u/d  VK   SC  State

  0: U+0000 down 00ff 007d 0000
  1: U+0000  up  00ff 007d 0000

Ok, the scan code is 0x7d. Now let's see what that 0xFF scan code is in winuser.h:

#define VK_ATTN           0xF6
#define VK_CRSEL          0xF7
#define VK_EXSEL          0xF8
#define VK_EREOF          0xF9
#define VK_PLAY           0xFA
#define VK_ZOOM           0xFB
#define VK_NONAME         0xFC
#define VK_PA1            0xFD
#define VK_OEM_CLEAR      0xFE

/*
 * 0xFF : reserved
 */


#endif /* !NOVIRTUALKEYCODES */

It looks like this is simply not a VK value, which explains why the code did not find a character!

Of course it is the keyboard layout DLLs that are created by MSKLC that have the job of mapping scan codes to virtual keys. So, now we know what to do, right? We just have to add the right entry to this table!

If you go into MSKLC and choose to save the US layout as a .KLC file (uscustom.klc), you can look at that file in Notepad.

Now just look at the end of a bunch of entries in the LAYOUT table, which look like this:

35 OEM_2    0  002f  003f  -1    // SOLIDUS, QUESTION MARK, <none>
39 SPACE    0  0020  0020  0020  // SPACE, SPACE, SPACE
56 OEM_102  0  005c  007c  -1    // REVERSE SOLIDUS, VERTICAL LINE, <none>
53 DECIMAL  0  002e  002e  -1   // FULL STOP, FULL STOP,

The first column is the scan code, the second is the virtual key minus the VK_, the third is the impact of the caps lock key, and the columns after that are the characters that show up.

So let's add one column just before the "53  DECIMAL" entry (which must be the last entry in the table). Since I am doing this with the US keyboard, I will use VK_OEM_8, a VK value that is not yet used (you can't duplicate scan codes or virtual keys):

7d OEM_8    0  00a5  00a6  -1    // YEN SIGN, BROKEN BAR, <none>

and now we'll compile this keyboard file (change the directory if you installed MSKLC anywhere special):

"C:\Program Files\Microsoft Keyboard Layout Creator\bin\i386\kbdutool.exe" -u -v -w -x uscustom.klc

It will create a uscustom.dll file which you can substitute in for the one MSKLC creates and puts in the uscustom\i386 directory. And you now have a keyboard that will make use of that key on the Japanese 106-key keyboard....

If you play around with the .KLC file later in MSKLC, the entry should remain intact; the only real limitation here is that you can't see the entry in the UI since there is no key there. Which is only the case because not even the Japanese keyboard handles it (this particular key's use is only mediated by the Japanese IME, currently!). Though I at one point suggested adding it to the US and other keyboards, I didn't get much support for it (sometimes I think I wouldn't have been able to get the VK_OEM_102 key added without a ton of proof that it was defined everywhere!).

Now things are a bit more complicated with keys that do not directly involve input, which is why I focused on this particular keyboard (and key). So try not to think of this post as opening up everything, okay?

In fact, there are many special issues involved with the numeric keypad and the cursor keys (and the additional shift state keys) that are involved here which make this more complicated (so I will talk about them another day, probably).

But you can think of yourself as being on the road now for pimping your keyboard beyond what MSKLC does....

Enjoy!

This post brought to you by ¥ (U+00a5, a.k.a. YEN SIGN)