by Michael S. Kaplan, published on 2007/11/16 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/11/16/6298366.aspx
See also the first law (VK_A is not always 'A')
The next law is also simple to state and occasionally obvious though more often it does not occur to people....
Not every keyboard contains every VK_* value
It is just so easy for people to attach functionality to keys based on their VK_* names.
Like an incrementing/decrementing functionality atop VK_OEM_PLUS and VK_OEM_MINUS.
But the truth is that very few keyboards have all of the values in them, so if your application relies on them being there then you will see some people unable to use it.
I even formally laid out some examples in Punctuation keys can make lousy shortcuts, previously.
And there is no rule intrinsic to keyboards that requires all of the VK_A to VK_Z values to always be present, either. Though usually they are and the only real problem is that one cannot assume their identity, since e.g. VK_A is not always 'A'.
Well, the way developers look for these values without remembering that the end user may not ever know about them or their identities can also be a problem.
This post brought to you by + (U+002b, a.k.a. PLUS SIGN)
# John Cowan on 16 Nov 2007 10:52 AM:
It seems to me that the moral of this story is that using the VK codes is never a good idea unless you want to capture action keys such as F1-F10, Ins, Del, Home, End, arrows, etc.
For anything alphanumeric you should be interpreting characters rather than keyboard events.
# Michael S. Kaplan on 16 Nov 2007 12:04 PM:
That is true -- though I have more proofs coming in the forms of additional laws that will support that conclusion further, first. :-)
referenced by
2012/05/02 Who owns keyboard testing?
2012/04/26 Michael's Keyboard Laws for Developers, Part 5