Who would win in a fight between VK_DECIMAL and LOCALE_SDECIMAL?

by Michael S. Kaplan, published on 2006/09/13 16:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/09/13/752377.aspx

What is that old expression about When it's time to railroad... again?

The other day, regular reader and MVP Mihai Nita asked in the Suggestion Box:

Recently I bumped into something, and I think is a Windows keyboard driver bug.

But since when blaming someone I like to give a chance to defense, so here it is:
- start Notepad
- select the Italian keyboard
- type a number using the NumPad, and use the dot/comma there (VK_DECIMAL)

This is it!
Can you see it?

VK_DECIMAL on Italian keyboard produces a dot! Same with French keyboard and some others. The German and Romanian keyboards produce a comma, (as I think they should). I did not try to fully review of all the keyboards, these are just some random examples.

Isn't VK_DECIMAL the "decimal separator" (as suggested by the name?). And isn't the whole idea of NumPad to allow typing numeric values in one place?

Excel is smarter and seems to do the right thing. Meaning if I press VK_DECIMAL, it will use the User Locale decimal separator (respecting my override also), and it completely ignores the current keyboard.

Yes, I can intercept the VK_KEYDOWN and deal with it (probably what Excel does), but don't you think is normal to get some help from the OS?

In the end there are only two answers:
- the keyboard drivers are wrong (and this is a chance to fix them, maybe for Vista :-)
- some national keyboard standards are wrong and the driver is just standard compliant (and then we learned something)

Ok, this is your topic suggestion :-)

And then, interestingly enough, Katya (don't follow the link to her blog if you don't know Russian!), our awesome contact in the MS subsidiary in Russia, also asked about the same issue:

Hi Michael,

I wonder if you could share your knowledge about the following problem: when entering numbers through numpad, some programs get VK_Decimal value and generate this symbol (Notepad, Word), while others like Excel look into LOCALE_SDECIMAL and generate this symbol.

I got a question from customer who has to deal with 3rd party app which seems uses VK_Decimal. But for Russian users it's inconvenient as they have to control in what keyboard mode they are, as in English keyboard, period is generated, while in Russian mode, coma is generated.

any hints how user can setup the keyboard to generate what is saved in LOCALE_SDECIMAL and to ignore what is in VK_decimal when Numlock is ON?

(yes, user has used MSKLC  to change VK_decimal value, but if there is any other way to resolve the problem?)

It is almost like when it is time for an issue to come up here that many people have the issue going on? When it's time to railroad... :-)

In any case, they are both right in the sense that:

However, Mihai is mistaken in believing this to a keyboard bug; it is a limitation in the architecture that keyboards are entirely data-based and have to be able to be called in the kernel mode component of USER (a.k.a. USERK) and is therefore unable to call user-mode functions like the NLS API function GetLocaleInfo. This is something applications can do (and it is something that Excel does, as both of them note), but not something that keyboards can do.

As for what is actually assigned to VK_DECIMAL, that is something that for every keyboard is either defined in a standard or decided by the person/people who submitted the keyboard layout. It may match the locale's preferences or it may not, but it is what it is and it is a tough argument to make that it should be changed since (for better or worse) the behavior in applications that do not override it amounts to an expectation of behavior, and changing it is a bad experience for users.

It is in fact the reason why keyboards almost never change, ever.

For what it is worth, this particular issue is one of the reasons why the VK_DECIMAL key is included in the MSKLC layout, even when the rest of the numeric pad is not.

But either way, it does make for an interesting blog post! :-)

 

This post brought to you by . (U+200e, a.k.a. FULL STOP)

# Maurits on 13 Sep 2006 5:05 PM:

"When railroading time comes you can railroad---but not before"
-- Robert A. Heinlein, The Door Into Summer

?

# Michael S. Kaplan on 14 Sep 2006 1:37 AM:

That is one of the references. Though I think that subconsciously I was pondering more about the way Doug Hofstadter described the "Magic Cube" back in his metamagical themas column in Scientific American -- how some ideas just get expressed when the time comes, and that there is not realy causality in it all....

# c2j2 on 14 Sep 2006 3:13 AM:

Mihai,

use the driver from http://www.sysinternals.com/Utilities/Ctrl2Cap.html and change it slightly so that it returns a comma instead of the dot.

Possibly looking through the www you can find such a driver already done, as it's not very rare to have that quest.

Christian

# Michael S. Kaplan on 14 Sep 2006 3:22 AM:

Hi Christian,

Yes, that is a solution just like a custom layout with MSKLC is -- but neither one provides a solution that makes the VK_DECIMAL value follow the default user locale's notion of LOCALE_SDECIMAL, including user overrides (which is what Excel does)....

# ReallyEvilCanine on 14 Sep 2006 10:31 AM:

Why not include the number pad in the KLC? It would let me change it to a hex keypad for entry as easily as I change keyboards now. I admit a bit of creativity is required but yes, some people actually spend a not-insignificant amount of time typing in hex values.

# Ivan Rouzanov on 14 Sep 2006 1:10 PM:

Interesting and related issue is that WM_CHAR brings character code and WM_KEYDOWN (and WM_KEYUP) - virtual key code, and key code like VM_DECIMAL has nothing to do with character code in the particular keyboard layout.

If one would think about applications like games it all makes sense - in those you want the key to work certain way no matter which layout is active now.
But in other applications and even standard controls like Edit and RichEdit you have a choice - for the same event (keyboard key was pressed) you receive multiple messages and it is up to you (or the control you use) which one to process and how.
And RichEdit reacts to WM_KEYDOWN in this case and Edit - to WM_CHAR. Thus Wordpad and Notepad behave differently.

# RubenP on 14 Sep 2006 5:35 PM:

I've always wondered (probably just me): why doesn't the US International keyboard provide the comma through Alt Gr + Num Decimal? It would make entering decimals though the number pad a little less painful for several non-English languages. (Though you do need a spare hand tapping the Alt Gr.)

I never knew Excel behaved the way it does. I must say: rather clever.

# Michael S. Kaplan on 14 Sep 2006 5:44 PM:

I like the Excel behavior, too. If there were actually a way to make it an OS-wide thing I'd pursue that, but there isn't. :-(

# RubenP on 15 Sep 2006 6:04 PM:

Maybe stuff like this should become part of the OS developer guidelines. There are so many nifty keyboard tricks inside Office either no-one knows about (like this one), or they only work inside Office and some-other-built-in-control-you-didn't-expect (alternatingly the plain text box, RichEdit or IE, but never all at the same time).

(If you look at XP's or Vista's UI guidelines, they're an unorganized mess, full of out-dated ugly screenshots and incomplete information and no consistency to find anywhere. Pity, as consistency is one heck of a UX booster. OMG, did I actually use the term UX in a meaningful context? ;-)

# Mihai on 16 Sep 2006 3:31 AM:

<<mistaken in believing this to a keyboard bug; it is a limitation in the architecture that keyboards are entirely data-based ... and is therefore unable to call user-mode functions like the NLS API function GetLocaleInfo.>>

Even with that limitation I can still see it as a keyboard bug, in some cases.
True, the keyboard driver cannot do what Excle does. But at least can map to VK_DECIMAL the decimal separator for that keyboard locale.
So, if the user locale is English and the keyboard is Italian, then I get comma. Is not perfect, but in most cases the two locales match. So on an Italian OS, with Italian user locale and using Italian keyboard, I will get the right thing.

# Michael S. Kaplan on 16 Sep 2006 7:25 AM:

Mihai -- the data is not available to the keyboard-- so it cannot map things as you suggest.

So the keyboard has a hard-coded mapping, and that mapping is based on whatever the source says it is.

# Mihai on 17 Sep 2006 9:48 PM:

<<the data is not available to the keyboard-- so it cannot map things as you suggest.>>
I understand this.
But it seems I don't explain it clear enough.
There is enough data for the keyboard creator to "hard-code the right thing." I know I design and Italian keyboard and I know that in Italian the decimal separator is comma, so I hard-code VK_DECIMAL to be comma.

<<So the keyboard has a hard-coded mapping, and that mapping is based on whatever the source says it is.>>
And the hard-coded mapping for the Italian keyboard can say (in the source) that VK_DECIMAL maps to comma. It is hard-coded, not dynamic in any way, not perfect, but better than dot.
This is why I say that the keyboard drivers are wrong or <b>some national keyboard standards are wrong</b>.

What I argue is this: take the Italian keyboard in MSKLC, change VK_DECIMAL to comma, and this is better than the current thing.
Playing with the DDK and keyboard drivers many years ago, I do understand that there is no way to get the Excel bahavior from the keyboard driver level.

I hope I have managed to explain it clear enough (three times, in three different ways :-)

# Michael S. Kaplan on 17 Sep 2006 10:00 PM:

Hey Mihai,

There is enough data for the keyboard creator to "hard-code the right thing."

Well, usually. But what do you do with layouts used in multiple places (like the 'US International' layout)? And in the end it is still up to the author of the keyboard.

It is someone else who is "wrong" by an arbitrary definition, sure. But we do not second guess the authors....

What I argue is this: take the Italian keyboard in MSKLC, change VK_DECIMAL to comma, and this is better than the current thing.

For a user, yes. For Microsoft, it has shipped this way in multiple versions and changing it could break someone. Better to not touch it, truly -- the risk of breaking someone expecting it to be the way it is would be much worse....

# Michael S. Kaplan on 17 Sep 2006 10:05 PM:

It would be a nice to have feature to consider in a future version of MSKLC, though probably only for new layouts rather than when loading from existing (in which case we should load from existing and not second guess it)

Though come to think of it, this may make a good validation warning either way -- I'll suggest this for a future version....

# Mihai on 18 Sep 2006 1:54 PM:

<<
<i>What I argue is this: take the Italian keyboard in MSKLC, change VK_DECIMAL to comma, and this is better than the current thing.</i>

For a user, yes.
>>

I only care about the user, I don't work for MS :-)

# Michael S. Kaplan on 18 Sep 2006 2:54 PM:

But as a request to change the one in the box, there are those wider issues to consider, of course.

# Mihai on 18 Sep 2006 5:33 PM:

<<But as a request to change the one in the box, there are those wider issues to consider, of course.>>

It was a smiley there :-)
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

2011/04/09 [Keyboard ]Solution Unsatisfactory

2008/12/08 The "plate of shrimp" theory explains it

2006/09/14 Why doesn't MSKLC have a numeric keypad?

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