When you have just one model, the easiest place to fall short is when something's missing…

by Michael S. Kaplan, published on 2012/04/03 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/04/03/10290188.aspx

Yesterday in When you have two different models, the easiest place to fall short is in the interaction between 'em…, I talked about the problems with the way there were two different models for time and date formatting, one of them clearly inadequate.

And how over the last several versions of Windows that POSIX model for date/time formatting had largely been gutted, to avoid duplication and the bugs that can, and occasionally have, come from duplication.

A pretty satisfactorily happy ending to the story, right?

Well, yes.

In fact, there is just one problem here.

And by one problem, I mean three problems: the formatting of numbers, currency, and percent values.

All three are supported only by (for lack of a better term, since some if them are in fact POSIX based) "POSIX"-style settings.

And we try to make up for the problems there by being somewhat exhaustive in our options.

The price?

Well, rather than a small number of properties, we have all of the following:

LOCALE_ICURRENCY, LOCALE_IDIGITS, LOCALE_IINTLCURRDIGITS, LOCALE_IMONLZERO, LOCALE_INEGATIVEPERCENT, LOCALE_INEGCURR, LOCALE_INEGNUMBER, LOCALE_INEGSEPBYSPACE, LOCALE_INEGSIGNPOSN, LOCALE_INEGSYMPRECEDES, LOCALE_IPOSITIVEPERCENT, LOCALE_IPOSSEPBYSPACE, LOCALE_IPOSSIGNPOSN, LOCALE_IPOSSYMPRECEDES, LOCALE_SCURRENCY, LOCALE_SDECIMAL, LOCALE_SGROUPING, LOCALE_SMONDECIMALSEP, LOCALE_SMONGROUPING, LOCALE_SMONTHOUSANDSEP, LOCALE_SNEGATIVESIGN, LOCALE_SPERCENT, LOCALE_SPOSITIVESIGN, and LOCALE_STHOUSAND.

A lot of them are closely connected and interdependent. Enough so that the table at the bottom of Locale Information Constants:

Closely Related Locale Information Constants

Many of the locale information constants previously listed are closely related, so that changing one affects the value of the others. The following table shows the relationships among these constants.

 is all quite woefully inadequate since all it really tries to cover is a few fields that you can change; the rest of the spaghetti mess isn't covered anywhere!

Well, okay.

Who cares if you need to take 24 separate properties with mostly undocumented connections between them instead of a much smaller number of properties with clear dependencies, as long as everything is covered, right?

I mean, it's not like we've never had confusing stuff come out of Microsoft before!

All things considered, we could forgive all this if support was adequate.

Do you hear the evil music soundtrack playing now?

Because despite those 24 properties, there is something missing here.

Something fairly crucial.

Like whether to put a positive sign in front of (or right next to in some other way) a number.

Try it out, see if you can figure out how to do it.

I'll wait.

Hint: there is no way to do it.

Didn't you ever wonder why they took out the LOCALE_SPOSITIVESIGN from intl.cpl and the example so seldom has a plus sign in it?

I think they notice that LOCALE_SPOSITIVESIGN wasn't really getting used! :-)

Whopsie Daisy!

Now all of this becomes an interesting challenge as one considers what WinRT's Windows.Globalization.NumberFormatting namespace could do here -- since in so many ways it uses a superior model for these thiings.

Well, except for trying to get the data from NLS on points like this one, I mean. Though one sometimes turns to one's parents for ideas/advice.

Oh well, there's always some random future version to work all of this out.

Or they'll probably figure something out for this version for the Modern stuff.

I should probably start talking about that new stuff one of these days, instead of just obliquely referencing it, huh? :-)

referenced by

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