by Michael S. Kaplan, published on 2005/01/25 08:34 -08:00, original URI: http://blogs.msdn.com/michkap/archive/2005/01/25/360240.aspx
Tor Lillqvist suggested I talk a little about the difference between CAPSLOCK and ShiftLock --
Something you might want to blog about some day: the difference between "CapsLock" and "ShiftLock". Especially determining programmatically whether the "VK_CAPITAL" key acts as CapsLock or ShiftLock for a certain keyboard layout (input locale identifier). (Something I needed to do recently, for somewhat complex reasons)
Currently I do it by checking with ToAsciiEx(). I select a key that generates different characters with and without VK_SHIFT, and where the result from the shifted key isn't simply the uppercase equivalent of the unshifted one. I.e. typically my code would select a key from the "digit" row.
I then check again with VK_CAPITAL toggled (and VK_SHIFT off), and if the resulting char is the same that just VK_SHIFT produced, I know that VK_CAPITAL should act as ShiftLock.
Well, of course I would always suggest using ToUnicodeEx instead of ToAsciiEx.... :-)
Of course its not that simple since it is a per-key setting (as you point out, usually the CAPSLOCK key does not cause the number keys to display their shift states). And then comes features like SGCAPS that take over the CAPSLOCK key in a big way. Check out the Hebrew keyboard some time in MSKLC and you'll see what I mean -- it just wreaks havoc with the notion of the key labelled CAPSLOCK locking the 'CAPS' state. The price of adding two new shift states.
The setting also gets weird when you add dead keys to the mix -- anytime you call ToUnicode or ToUnicodeEx and the key is a dead key you will have that weird stateful situation which will affect the next call in the same thread. Though of course people who author keyboard layouts with dead keys that span multiple shift states probably do not like their users too much -- thats a hard typing task!
The setting in question here is actually available in MSKLC. We argued about the name of the setting for some time before finally settling on the "caps = shift" option. I had voted for "caps == shift" but was outvoted by the program managers to 2 to 1 -- maybe I should have invited some other developers?
Anyway, the MSKLC setting is actually automatically applied when the characters are cased variants of each other, and it is used in validation -- if the two characters are case pairs yet this option is not enabled (or if they are not case pairs yet the option IS enabled), you get a warning. But this is okay if it is intentional -- usually, it's not, though. After MSKLC was available we found out how often Microsoft had done this setting improperly in the build-in keyboards in Windows!
So, the summary -- for the CAPSLOCK to act as a ShiftLock, one must explicitly ask it to be so in the keyboard layout -- and often the layout author does not do this (even if that was probably the intention).
This post brought to you by "±" (U+00b1, a.k.a. PLUS-MINUS SIGN)
# Philip Newton on Tuesday, January 25, 2005 10:18 PM:
# Michael Kaplan on Tuesday, January 25, 2005 10:54 PM:
referenced by