by Michael S. Kaplan, published on 2010/09/28 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/09/28/10068553.aspx
Just over this last weekend, while I was off at Fremont Oktoberfest celebrating my birthday, friend/colleague/regular reader Doug Ewell was busy writing me mail:
At http://www.europatastatur.de/info1-9995-3.pdf you can find Karl Pentzlin's proposal, supposedly approved and published this August, to overhaul ISO 9995-3, among other things by adding a fifth shift state.
Almost all of the combining diacritics (usually implemented in Windows as dead keys) reside in this fifth state.
What is the best way, using MSKLC and other standard Windows techniques (i.e. not a third-party layer), to implement this keyboard? MSKLC Help tells me to stay away from the Ctrl and CapsLock states if at all possible.
[Feel free to make this a blog in your Blog if you like.]
I'm glad someone was holding down the fort while I was out abusing my liver with friends! :-)
Anyway, I came back to a whole big thread with contributors like Karl Pentzlin and Alain LaBonté discussed some of the many issues here. Thankfully, the contributions fell into a few broad categories in regard to interest, position, and motivation:
Now all three of them are completely accurate and correct. Mostly. I mean, close enough for our present purposes, and I am not one of those annoying prigs who will correct people on terminology issues and other such trivia....
But I'll share my thoughts here.
My credentials (by which you can judge the validity and/or applicability of my contribution!):
First of all, there is an MSKLC help topic that I wrote, the text of which is:
Avoiding the Ctrl Shift State
While it is possible to define characters for both the Ctrl and Ctrl+Shift shift states, it is highly recommended that you avoid doing this if you can, for two reasons:
* There may be conflicts with common applications such as Microsoft Word, which use the "Control" key for its intended purpose - control functions. Generally speaking, they will handle the WM_KEYDOWN message (which contains the VK value). Because of this, your keyboard layout will never see that message translated into a WM_CHAR message (which contains the characters). These applications document their usage of these Control keys
You may rely on many of the same features without realizing it when hit Ctrl+S to save, etc.
* Even if the application does not try to wrest control of these keystrokes, Windows internally tends to map the Ctrl shift states for VK_A - VK_Z to Unicode control characters any time the keyboard layout does not map them. This little known feature has been a part of Windows for a long time, and there are people assuming it will always be true, for compatibility with old DOS-based applications.
If you feel you must use the Ctrl shift state, then at least consider avoiding VK_A - VK_Z (which is where most control functions would be kept) and also consider not putting any vital characters in your keyboard layout there, to guard against when the application blocks your layout's desired input.
You may notice specific keys in the Ctrl shift state are assigned when you load an existing keyboard layout. These key assignments are used in certain legacy applications like Microsoft HyperTerminal and should usually not be removed.
This is what Doug mentioned, about the recommendation to avoid these shift states.
You won't die (or be killed!) if you use them, but you will have to live with the times that you don't get what you want from them, because an application puts its own needs first.
Now second of all, and Alain will have to forgive me here on this point (or he could choose to not do so and just be unhappy with me, but I hope he will not take it in that direction), I don't really care for the Canadian Multilingual Standard keyboard layout, as I explained in Getting all you can out of a keyboard layout, Part #9a and Getting all you can out of a keyboard layout, Part #9b.
You can think of the code behind these blogs as proof that I could have theoretically written the MSKLC feature to create such keyboards as ones that assign the "LEFT" shift state characters and the "RIGHT" shift state characters as different shift states, were there not tortuously complex usability reasons in the tool to avoid doing so. :-)
Now this points to yet another reason that I don't like the keyboard layout: after stating why I think using the CTRL shift states is bad, this keyboard not only does that; it does it twice!
Now this indirectly answers one of Doug's main concerns. Yes, MSKLC recommends against using the CTRL shift states, but the Canadian Multilingual Standard keyboard, considered by some of those creating multilingual keyboard standards based on ISO 9995-3 to be a model, does it with impunity. Therefore, by their definition, the CTRL shift states are just fine for a fifth shift state, at least!
Okay, there is one problem solved. Well, solved enough for present purposes (I have palmed a card here that I may talk about some other day if someone noticed the card in question!).
Another problem, which I described in other blogs like It is not easy to chain dead keys on Windows and other blogs like Those keys aren't going to be extended; they're dead! and Only ONE WCHAR per dead key in particular, is that the standard, which has many times that it describes a dead key feature that can support a result that has multiple Unicode code points in it.
They describe a feature Windows cannot do. The closest we come if what I describe in It is not easy to chain dead keys on Windows, which is nowhere near close enough.
Plus the fact that no one has ever described how to do the dead key chaining thing anyway makes it much more challenging, too. Though since most of the definitions would fail anyway it isn't too much of a loss.
MSKLC definitely doesn't support it, again in part to avoid the usability issues it would cause with the current UI and the heavy limitations on what would work.
Now I have been someone to strongly make this point. I did it for years in this blog, I did it when Erkki was working on the Finnish standard and I heavily impressed the issue several times on Microsoft representatives who attended some of the meetings that eventually became that ISO standard, and several others who have been involved with the standard all along.
I find myself dissppointed though perhaps unsurprised that a standard would be written that way despite such feedback, particularly from vendor whose lack of support would generally limit the overall adoption of the standard in the market.
But then I remind myself that there are many standards that do not get fully implemented by every (or even any) vendor -- like the SQL Standard, for example.
I guess these various standards put out there for keyboards that ask for more than the platform can give may have to be in that category....
referenced by
2011/04/16 Chain Chain Chain, Chain of Dead Keys