Sorting it all Out

Deadkeys don't require that you type the accent first, do they?  On a Mac you can make layouts where the vowel is the deadkey and what diacritic is added depends on the next key you hit.

Hi, I just discovered your blog while searching for a solution for a MSKLC-related bug (? to be confirmed). I wonder if this is the right place to post such reports, but it will also allow me to reflect on your opinion about dead keys.

So let’s see this dead key issue first. Yes, combining characters are great, and I have nothing against the Unicode principle of them following the base character. However, and I’m sure you know this just as well as me, dead keys are commonplace for several non-US (e.g., French) keyboards. People are pretty well used to them, and these kinds of habits just don’t go away. Moreover, support for combining characters is a very recent addition to Windows: I am told they work under Word 2007 but, in my experience, not under Word 2003, which an awful lot of people still use. Also, under XP (e.g., Notepad), the equivalence of the base+combining pair and the precomposed character is not respected, which is a major issue (when searching for the word passé I won’t find passé, see the difference?).

Recently I considered deploying combining character-equipped custom keyboard layouts in a big company, but I immediately discarded the idea once I realised that these issues could not be resolved.

Which brings me to my main topic: while developing a custom French keyboard with MSKLC, I ran into a strange error which might be a bug. I was trying to reproduce some Word-specific French character combinations such as Ctrl+' which is basically a dead key for the acute accent. So in MSKLC I defined Ctrl+' (that is, VK4) as a dead key that gives ÁÉÍÓÚáéíóú when followed by AEIOUaeiou. Also, I wanted to used the same dead key to type a regular (i.e., typographic) apostrophe U+2019 when followed by a space:

U+00B4 (dead) followed by U+0020 => U+2019

It all works perfectly fine in the test window of MSKLC. However, when I create and install the DLL, the behaviour is altered: Ctrl+' is not a dead key anymore, and pressing it results in two (!) apostrophes (U+2019) being displayed. Upon opening the installed keyboard with MSKLC, I see that the key’s definition has indeed changed: Ctrl+VK4 gives U+2019 U+2019.

A similar, although not equivalent, problem occured when trying to define Ctrl+è (that is, VK7) as a dead key for the grave accent. This time, once the custom keyboard installed, the combination Ctrl+è becomes AltGr+è.

The KLC source file contains the right information. These alterations occur with the installed package only.

Any solutions or ideas? I can provide you with more information or the source KLC file if necessary.

Thanks a lot in advance, cheers,

Gábor

Lots of people are very happy with dead keys, and have been for decades. Irish keyboards, for instance, and most of the keyboards on the Mac OS, used deadkeys. You might (and do, as you say) prefer other methods of input, but there's a big difference between that and telling those who don't that they are benighted and should adopt different methods of input.

Michael,

thanks for answering! :)

I had read many of your posts (especially those related to the question) before, but the reason why I re-asked this question was because it seemed to me that this limitation is mostly kept just to be kept. You said:

Even if this ever were changed in a future release of Windows, it could not be used on existing versions due to the backcompat break that this would cause -- and the future version of MSKLC would have to support different keyboard layout DLLs for different versions of Windows.  Which as I am sure people can imagine is not a terribly popular plan....

So, it seems to me that it's not being updated purely for the sake of backwards compatibility, and while backcompat is a good thing, I don't believe that it should block progress (otherwise we would still be using DOS, wouldn't we?). Sure, I understand that even if Windows 8 would extend the possibilities here, we would still have to work around the limitation for Windows 7, Vista, XP etc. That's normal. Not so normal is limitations in legacy systems causing limitations in new ones. I hope you get my point... :)