by Michael S. Kaplan, published on 2008/06/30 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/06/30/8669810.aspx
In general, people will follow the defaults more often than they will override them.
The simple fact of human nature and how humans relate to software is why stuff like I talked about in What it means to be in the default install ends up being so effective in changing the perception of the application in all situations by simply changing the default.
Because if most people accept the defaults, then most people will get the defaults....
Now over in the Suggestion Box, Andy asked:
Hi Michael,
Do you know why Ctrl-Space is mapped to the space character in many keyboard layouts instead of leaving it unmapped like most other Ctrl combinations?
I was working on the keyboard handler of a terminal program and was trying to give priority to the keyboard layout wherever possible. Ctrl-Space is meant to send 0x00, so I was quite surprised to get 0x20 instead, but quickly tracked it down to the keyboard layout. It's easy to override of course, but it still seems curious as it's a shortcut in many applications anyway.
Now there are three different "defaults" at work here:
#1: The command line tool that builds keyboard layout DLLs, whether in
both have an interesting behavior in regard to the SPACE character (scan code 0x39, virtual key VK_SPACE) -- if the key is not assigned in the base, shift, or control states, a space (U+0020) is assigned automatically.
The upside is that for most keyboards that have been built and shipped in NT-based Windows since March of 1995 (when the tool was first built), the space key has been inserted any time something else wasn't. Which is to say most times.
#2: MSKLC's Load Existing keyboard... functionality takes existing keyboards and loads them up. Since most existing keyboards have U+0020 assigned to all three shift states and since most users never assign any of these three states on the shift key, the default setting persists.
#3: MSKLC's creating a blank keyboard functionality, because although not the most common ways that keyboards are created, it begins the life of a layout free from the "defaults" of #1 and #2, above.
Users have the opportunity to change the layout if they would like to, but most people do not.
MSKLC has a slightly different default of its own, though -- it assigns U+0020 to the space bar in the base and shift states, but not the control state. It breaks free of the defaults of the past.
Its default is to assign nothing there.
That difference could in theory be thought of as a legitimate bug in MSKLC....
However, it doesn't really matter. When you are done and you build your keyboard, MSKLC calls kbdutool.exe to do the build, and the unassigned CONTROL+SHIFT will be given U+0020 due to #1, above -- unless you override the default.
Which almost no one ever does, since almost no one ever changes the defaults....
This blog brought to you by U+0020, aka SPACE)
Andy on 6 Jul 2008 8:25 AM:
Thanks for the quick and comprehensive explanation, so probably just a case of "it seemed a good idea at the time" when kbdtool was build.
(I twice managed to overlook your post when I checked back earlier in the week since I didn't expect it be so far down the page already. Good luck with your quest to empty suggestion box quest! )