Punctuation keys can make lousy shortcuts

by Michael S. Kaplan, published on 2006/04/02 21:35 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/04/02/567003.aspx

A good example of a question that gets asked fairly often was in my inbox not too long ago:

I’m converting to Whidbey ToolStrips and have a question about ShortcutKey:

We’re using CTRL+< and CTRL+> for navigating to “previous” and “next” items. It’s CTRL and the comma and period key on my US keyboard.

I’m using Ctrl+Oemcomma and Ctrl+Oemperiod in the ShortCutKeys property and “CTRL+<” and “CTRL+>” in the ShortCutKeyDisplayString properties.

Do all international keyboards have a < and > in this position?

Is this the right key to be using for next and previous navigation? It seems like some users might be motivated to attempt CTRL SHIFT to get to the < and >

Now this same question has come up many times, most recently with people trying to use VK_OEM_MINUS and VK_OEM_PLUS to do something that would be able to make good intuitive use of a PLUS and MINUS key.

Unfortunately, the fact is that not every keyboard layout contains every single VK_OEM_* 'punctuation' character. Whether you want to attribute it to the problems I pointed out in this post or whether you place some of the blame on the fact that not all keyboard layouts contain all types of punctuation, any attempt to universally place any kind of shortcut will prove to be no shortcut at all in some cases....

Running some basic code that uses MapVirtualKeyEx with the various VK_OEM_* values shows the following keyboards which do not contain the VK values, on an XP SP2 machine (filtering out the IME keyboards since they fall into an entirely different category!):

Keyboards missing VK_OEM_PLUS:
Bulgarian (00000402)
Slovak (0000041b)
Turkish Q (0000041f)
Latvian (00000426)
Luxembourgish (0000046e)
Swiss German (00000807)
Swiss French (0000100c)
Spanish Variation (0001040a)

Keyboards missing VK_OEM_MINUS:
French (0000040c)

Keyboards missing VK_OEM_102:
Azeri Latin (0000042c)
United Kingdom Extended (00000452)
United Kingdom (00000809)
Irish (00001809)
Gaelic (00011809)

Keyboards missing VK_OEM_8:
Arabic (101) (00000401)
Chinese (Traditional) - US Keyboard (00000404)
Czech (00000405)
Danish (00000406)
German (00000407)
Greek (00000408)
US (00000409)
Spanish (0000040a)
Finnish (0000040b)
Hebrew (0000040d)
Hungarian (0000040e)
Icelandic (0000040f)
Italian (00000410)
Japanese (00000411)
Korean (00000412)
Dutch (00000413)
Norwegian (00000414)
Polish (Programmers) (00000415)
Portuguese (Brazilian ABNT) (00000416)
Romanian (00000418)
Russian (00000419)
Croatian (0000041A)
Albanian (0000041c)
Swedish (0000041d)
Thai Kedmanee (0000041e)
Urdu (00000420)
Ukrainian (00000422)
Belarusian (00000423)
Slovenian (00000424)
Estonian (00000425)
Lithuanian IBM (00000427)
Farsi (00000429)
Vietnamese (0000042a)
Armenian Eastern (0000042b)
FYRO Macedonian (0000042f)
Georgian (00000437)
Faeroese (00000438)
Devanagari - INSCRIPT (00000439)
Maltese 47-key (0000043a)
Norwegian with Sami (0000043b)
Kazakh (0000043f)
Kyrgyz Cyrillic (00000440)
Tatar (00000444)
Bengali (00000445)
Punjabi (00000446)
Gujarati (00000447)
Tamil (00000449)
Telugu (0000044a)
Kannada (0000044b)
Malayalam (0000044c)
Marathi (0000044e)
Mongolian Cyrillic (00000450)
Syriac (0000045a)
Nepali (00000461)
Pashto (00000463)
Divehi Phonetic (00000465)
Maori (00000481)
Chinese (Simplified) - US Keyboard (00000804)
Latin American (0000080a)
Belgian French (0000080c)
Belgian (Period) (00000813)
Portuguese (00000816)
Serbian (Latin) (0000081a)
Azeri Cyrillic (0000082c)
Swedish with Sami (0000083b)
Uzbek Cyrillic (00000843)
Inuktitut Latin (0000085d)
Canadian French (Legacy) (00000c0c)
Serbian (Cyrillic) (00000c1a)
Canadian French (00001009)
Bosnian (0000141a)
Bosnian Cyrillic (0000201a)
Arabic (102) (00010401)
Bulgarian (Latin) (00010402)
Czech (QWERTY) (00010405)
German (IBM) (00010407)
Greek (220) (00010408)
United States-Dvorak (00010409)
Hungarian 101-key (0001040e)
Italian (142) (00010410)
Polish (214) (00010415)
Portuguese (Brazilian ABNT2) (00010416)
Russian (Typewriter) (00010419)
Slovak (QWERTY) (0001041b)
Thai Pattachote (0001041e)
Turkish F (0001041f)
Latvian (QWERTY) (00010426)
Lithuanian (00010427)
Armenian Western (0001042b)
Hindi Traditional (00010439)
Maltese 48-key (0001043a)
Sami Extended Norway (0001043b)
Bengali (Inscript) (00010445)
Syriac Phonetic (0001045a)
Divehi Typewriter (00010465)
Belgian (Comma) (0001080c)
Finnish with Sami (0001083b)
Arabic (102) AZERTY (00020401)
Czech Programmers (00020405)
Greek (319) (00020408)
United States-International (00020409)
Thai Kedmanee (non-ShiftLock) (0002041e)
Sami Extended Finland-Sweden (0002083b)
Greek (220) Latin (00030408)
United States-Dvorak for left hand (00030409)
Thai Pattachote (non-ShiftLock) (0003041e)
Greek (319) Latin (00040408)
United States-Dvorak for right hand (00040409)
Greek Latin (00050408)
US English Table for IBM Arabic 238_L (00050409)
Greek Polytonic (00060408)

Now a few important things to keep in mind here:

it is probably never a good idea to use VK_OEM_8 since there are more keyboards that don't use it than just about any other (ditto for any other rarely used VK_* value);
it is entire possible that a layout can use any of these keys for any purpose -- so assuming a particular character is what will be on the key is probably a bad idea;
having some assignment to a VK_* value of any kind on a keyboard layout gives no actual information on where a user would type to get that VK value, or whether the key even exists on their hardware;
shortcuts only count as shortcuts if they are available to users, so a well-behaving application should perhaps make the shortcuts easily configurable.

This post brought to you by "+" (U+002b, a.k.a. PLUS SIGN)

# NBC on 3 Apr 2006 3:29 AM:

So is it better to use Char Code than VK_Codes and Scan_Codes ?

# Michael S. Kaplan on 3 Apr 2006 3:45 AM:

Well, the truth is neither scan codes nor virtual key values nor char codes will give you a universal way to get at the entry across all of the hardware and software choices that are possible....

If you recognize this fact and then add your shortcut and then perhaps add a way to override the shortcut, then you have pretty much done the best that you can.

# Centaur on 3 Apr 2006 12:01 PM:

“shortcuts only count as shortcuts if they are available to users, so a well-behaving application should perhaps make the shortcuts easily configurable”

Oh. Then, in all my Windows life, I have seen maybe two well-behaving applications, namely Winword and Visual Studio.

# Michael S. Kaplan on 3 Apr 2006 1:22 PM:

Hi Centaur,

It is actually even worse than that, since they both have the problem I had discussed before at http://blogs.msdn.com/michkap/archive/2006/03/15/552031.aspx and http://blogs.msdn.com/michkap/archive/2004/12/28/333168.aspx (VS is a bit easier to configure than Word and does not have as many known conflits, but both of them have the problem to some extent).

# Michael Dunn_ on 3 Apr 2006 4:51 PM:

I've seen some languages that use "?" instead of "Help" on the menu bar, and the mnemonic is Alt+?. Is that practice going away?

Danish/Swedish keyboards have < and > on the same key and it's between the left shift key and Z - quite annoying for anyone used to having a double-wide shift key there. When I was travelling last year, I was having a really hard time with the European keyboards - it took me a while just to find @

# Michael S. Kaplan on 3 Apr 2006 5:16 PM:

Hi Mike,

I don't think any practices are going away -- but I would not bet my life that every keyboard layout will support them. :-)

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

2008/07/16 The situation was quite grave when I realized how "tepid" those hot keys were

2008/06/19 Accelerator vs. Shortcut, revisited

2007/11/16 Michael's Keyboard Laws for Developers, Part 2

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