Do your utmost to be conventional (and then pimp, q.d. or p.r.n.)

by Michael S. Kaplan, published on 2008/05/17 03:01 -04:00, original URI:

The message I got the other day via the Contact link was very well-timed:

Hello Michael,

I don't remember where was it, that I read you were the author of the Microsoft Keyboard Layout creator, but well... here I am, emailing you because I found a very nasty aspect of layouts created with the tool.

The issue is, layouts created with it, do not map Ctrl+<key> to the correct value, say I create a Dvorak variation, and use it... Ctrl+T should open a tab when using Internet Explorer, but it doesn't, since it windows thinks Ctrl+K is being typed in (since T in Dvorak is located where K is in QWERTY).

I was wondering if there was a way to solve this in a reasonably elegant way, or if you could point me out to a tool with such capabilities, or the source for compiling my own driver/layout.

I wait for your reply and thank you for your attention,


Another keyboard post -- Goldie'll probably never see it, even if I say stuff about her later in the post?

Hopefully the text of the Contact page was something Jamiel read since although I am giving the note my attention, I'm not directly responding to it except via this blog you are reading now. :-)

I'll tell a story to provide some context.

The very first build of MSKLC I let them try out was missing the most commonly used feature -- loading an existing layout and modifying it. As I mentioned way back in January 2005 in Accessibility, Internationalization, and Keyboards (#3: MSKLC's UI), while talking about the backasswards development process of the tool in general and this feature in particular:

Although it is last on the list here, it is probably the most commonly used feature, and it highlighted the pattern of those weekly meetings. I would show the current state of the UI, Simon or Cathy would bring up a feature they felt was crucial, I would push back and explain why it was not feasible, they would grudgingly accept this, but the issues they brought up would keep bothering me until I thought of a way to make it feasible. Then I would show it to them the next week. I am pretty sure that was how the meeting became known as D&P in the first place....

This particular feature is one I pushed bask on, hard. Because even before I knew how much work it would truly be, I knew it would be a lot of work. It just didn't seem to be worthwhile.

But then, over the weekend (the D&P was on Friday), I tried to build a keyboard.

I felt a bit like Stan and Kyle in that South Park episode (A Very Crappy Christmas) where they were creating a cartoon using the same techniques that Matt and Trey originally used for the shorts before the show. You know, excited when the first key was done, and then as each successive keystroke was assigned and I realized what a huge horking pain in the ass creating a keyboard from scratch could really be, I just got more and more annoyed.

By the eighth key, I was ready to rethink the whole idea of no "load an existing layout" functionality....

By the eleventh, I stopped creating the keyboard and started prototyping this new feature.

So now, thinking about Jamiel's message, I realized the process he had to be using to build the Dvorak keyboard. He was changing the assignment of very single key and every shift state!


There was no way that this was fun. :-(

Let's take a step back here to solve this problem, though. I mean, after all, there is a Dvorak keyboard in Windows we can look at.

First we have the plain old US keyboard layout:

and then we have the United States - Dvorak keyboard layout:

The hint about the difference between Jamiel's layout and the one above is in the ToolTips, but to be more explicit let's right-click, we are talking:


or to be more explicit and launch that dialog, we re looking at:


In fact, the only way to see what ties these two different assignments to that one key is to check the Advanced View and look at:


and note that they share a common scan code of 25.

Let's look at the two .KLC files, say sampling the key in question and a few on each side, for US:

23   H      1   h      H      -1    // LATIN SMALL LETTER H, LATIN CAPITAL LETTER H, <none>
24   J      1   j      J      -1    // LATIN SMALL LETTER J, LATIN CAPITAL LETTER J, <none>
25   K      1   k      K      -1    // LATIN SMALL LETTER K, LATIN CAPITAL LETTER K, <none>
26   L      1   l      L      -1    // LATIN SMALL LETTER L, LATIN CAPITAL LETTER L, <none>
27   OEM_1  0   003b   003a   -1    // SEMICOLON, COLON, <none>

versus United States - Dvorak:

23   D      1   d      D      -1    // LATIN SMALL LETTER D, LATIN CAPITAL LETTER D, <none>
24   H      1   h      H      -1    // LATIN SMALL LETTER H, LATIN CAPITAL LETTER H, <none>
25   T      1   t      T      -1    // LATIN SMALL LETTER T, LATIN CAPITAL LETTER T, <none>
26   N      1   n      N      -1    // LATIN SMALL LETTER N, LATIN CAPITAL LETTER N, <none>
27   S      1   s      S      -1    // LATIN SMALL LETTER S, LATIN CAPITAL LETTER S, <none>

Now obviously there are at least two different lessons one can learn here....

One could have the lesson of loading existing layouts when you can in order to make keyboard development easier. :-)

Or one can take an existing .KLC file and modify the hell out of it to make keyboard layout with. The format is not publicly documented, but most of it is pretty self-explanatory: it is how we used to build all keyboard layouts before there was a tool. And you can even have this handy scan code map to help:

To be honest I wish I had this back in the early days, myself.... :-)

Now the best answer is probably between these two extremes -- load an existing layout, and then modify the .KLC file to pimp as necessary!

This blog brought to you by(U+2387, aka ALTERNATIVE KEY SYMBOL)

# Mihai on 19 May 2008 1:23 PM:

Interesting article. But I think it does nothing to explain the problem :-)

Most likely the IE accelerator table (like many others) use the VK codes. Which don't change, no matter how much one plays with MSKLC.

# Michael S. Kaplan on 19 May 2008 1:43 PM:

Actually, you are mistaken -- the tricks in this article DO change the VK codes; that is the whole point of why what Jamiel was doing was not working! :-)

BalintN on 7 Jan 2009 6:28 PM:

Hi, I might be dumb, but I have a similar / same problem, and I don't understand the answer:

Say, I want to program CTRL-Z on CTRL + Z (on the key that is Z in the US layout).

How can I do that?

Michael S. Kaplan on 7 Jan 2009 9:32 PM:

The CTRL shift state allows you to assign letters -- so you can put them on that Z. Load the keyboard you like and then modify the one you loaded to create your new one....

BalintN on 8 Jan 2009 5:47 AM:

Hi Michael,

I did just that, but it does not work the way I'd expect.

I have a Hungarian / Hungarian keyboard layout - I imported that. It contains the ZY letters flipped (like the German keyboard), it is QWERTZ. If I count lines from the top, Z is on line 2, and Y is on line 4.

I'd like to move Z to line 4, and Y to line 2 (in the English-like QWERTY order).

I did that, but CTRL-Z remains in line 2.

So I checked the Ctrl shift-state, and placed ZY in their QWERTY places - but CTRL-Z (undo) behaviour remains in line 2.

What am I missing?

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2010/07/07 [Pretty much] All the things you can't do with SGCAPS, and why

2008/11/04 Strange control over CTRL and control characters

go to newer or older post, or back to index or month or day