by Michael S. Kaplan, published on 2010/04/05, original URI: http://blogs.msdn.com/b/michkap/archive/2010/04/05/9988581.aspx
Over in the Suggestion Box, RQ asked:
Hi Michael,
I've been using MSKLC to create an improved keyboard layout for Lithuanian, and have a question now based on the feedback I received:
The thing is that while most notebooks allow to simulate numeric keypad by pressing the Fn-key plus certain keys on the right (e.g. JKL produces 123), most manufacturers have made this function pretty useless, because in their products, without NumLock turned on, Fn plus those key presses just move caret, and with NumLock on, it becomes impossible to type letters using those keys. The solution to this problem would seem to override the functions of Numpad keys to make them always generate numbers. Currently it's impossible using MSKLC. I even edited the klc file manually, and compilation failed because VK's like NUMPAD1 were not recognized.
So the question is: is it possible to override numpad keys from a layout? If yes, then:
1) perhaps support for this could be included in the next version of MSKLC?
2) can I trick the current version of KLC to do this? Or maybe I could run some commands from command line to compile such layouts manually?
Thanks,
Rimas
This question seems to come up fairly often, all things considered. Like in all of the following blogs from this Blog:
and so on.
In fact you may recall in one blog (Pimping the numeric keypad) that I claimed one could update them from the command line.
I said that based on a text file that sits in the same place as the kbdtool.exe that Windows itself uses, that one that kbdutool.rexe was based on, which has the following information in it:
Default Entries
----------------
Certain keys which are common to all keyboard layouts have default entries
created for them by kbdtool.exe.
These may be overridden by specifying them in the LAYOUT section.
This file, which is itself as old as the hills with very littl change since it was first written, was apparently not updated when some later change was made to the tool, as any attempt to update the NUMPAD* keys fails with an error about the scan code redefinition followed five other compiler errors right after. This happens in both the Windows one and the MSKLC one.
This technique works for other keys like VK_OEM8 as I have covered before, but the numbers and other keys on the numeric keypad can't be defined. Therefore, it isn't available as an option, and is really out of scope for the tool anyway (which is why no one ever noticed this).
But beyond that, getting to the specific scenario of the report....
This desire to get the "input Unicode code points" feature would still not work anyway to solve RQ's reported problem, even if there were a numeric keypad, as the FN thing can't be hacked in MSKLC. Even by the keyboard layout DLL.
It is done at a much lower level than the keyboard layout DLL (it is the way that laptop manufacturer's "hack" their keyboards to fake additional characters, and the actual scan code values underneath are modified for things to work).
It is (for example) the kind of trickery that lets you type CTRL+ALT+BACKSPACE to hit the login screen on a MacBookPro running Windows under Boot Camp, or all manner of other such trickery.
In the case of the numeric keypad, there is already a bunch of trickery happening, and what the laptops do here isn't good enough given the steps required for this input method:
This method works regardless of any of your language settings, but is the most cumbersome to type.
1.Press and hold down the Alt key.
2.Press the + (plus) key on the numeric keypad.
3.Type the hexidecimal unicode value.
4.Release the Alt key.
Alas, this appears to require a registry setting. It was already set on my computer, but some readers report that this method didn't work for them, and this is probably why. If you don't know what the registry is, please don't try this. Under HKEY_Current_User/Control Panel/Input Method, set EnableHexNumpad to "1". If you have to add it, set the type to be REG_SZ.
Note that I shamelessly stole this from the "Universal" method described in How to enter Unicode characters in Microsoft Windows. If you think about both the steps that the Fn-based laptop solution requires and steps 1-4 above you could probably guess why there might be problems here, as the Dell/HP/Toshiba trickery is trumped by the trickery in this method of input.
The fix for THAT problem is not a keyboard layout hack; it is those OEMs (are any of them, or their Microsoft TAMs, readers of this Blog?) rethinking their NUMLOCK support on laptops, because only by allowing a completely unfettered way to get to the numeric keypad can this be not only practical but even possible!
I thought I'd talk about Lithuanian for a minute, since it seems to be almost a MacGuffin in this whole story, perhaps intended to pique my interest more than a retread of the numeric keypad issue would (I admit I had been planning to eventually talk about how to override those keys which would have made Pimping the numeric keypad a choice bit of foreshadowing).
But then I discovered that it was not in fact possible with the unaltered tools as it seemed it would be, ruining the foreshadowing, so I figure at least I can hurt the MacGuffin's stature a bit as well. Not strictly logical as an argument, but then I am not always strictly logical as an arguer!).
Lithuanian holds an interesting place as it is the one European Latin-script based language that has attested examples (in "Old Lithuanian" documents) of characters involving mutliple diacritics that have no "composed" characters in Unicode and therefore require the "decomposed" form to be used. It also (incidentally) makes it yet another language that has problems with dead-key based keyboards in Windows, but note that this is not exactly due to the lack of these "composed" characters (after all both Polytonic Greek and Vietnamese have the characters and they have the problem as well). These characters eventually were defined as named sequences in Unicode to try to help folks compose themselves about the need to stay decomposed. :-)
As a random, unrelated Lithuanian factoid: Lithuanian and Latvian have had their ups and downs in Windows, with changes requested in the Vista time-frame after groups of people were unhappy that letters with primary distinctions in dictionaries were treated as letters with diacritics. In the case of Latvian, however, other groups came back before Windows 7 was released complaining that a Latvian standard admitted this difference while also wanting the ability to do searches where the diacritics which were not to be treated as diacritics could nevertheless be optionally ignored in matching though perhaps not in sorting. In Lithuania we were spared this odd and unruly directive (I no longer owned sorting when that bug report came in, about a year ago, so I was spared the Latvian issue as well except as a consultant/historian who could dig up the old mail threads).
As another random, unrelated Lithuanian factoid: Lithuanian's general "lumping in" to code page 1257 (along with Latvian and Estonian) was a necessary consequence of the other code pages being too full to hold all the characters needed; it was a slightly ironic twist that caused a nameless southern hemisphere locale added years later that would have been better served by cp1257 but was instead given cp1252 as an ANSI code page since that reflects the practices of applications in the area anyway. The fact that things close to Australia are hardly "Baltic" while cp1257 *is* may also have been a minor factor, but we could have just changed the name if we needed to!
Getting back on topic here at the end....
Luckily, letters for Lithuanian can be put right on the keyboard, as well. Even those older letters, if they are needed (just not as dead keys). That would be much easier to type than putting the Unicode code points into a pseudo-numeric keypad like laptops have!
UPDATE 6 April:
It is the shift that throws in the confusion there; if you have such an "Overlay" key (or if CAPS LOCK does the same thing - one of my computers did, the other two did not) then you can even get the UNICODE CHAR functionality to work:
<fn>+<F6> <----- [numlock]
<caps lock>
<ALT> <----- {hold down ALT while hitting the next 4 keystrkes}
J <----- 1
K <----- 2
L <----- 3
U <----- 4So if your laptop has an "overlay" key, or if capslock gives you the same functionality, you can make the NUMPAD work well enough for the input of Unicode chars via the <ALT+> method.....
Thanks as usual, Marc! :-)