by Michael S. Kaplan, published on 2012/05/22 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/05/22/10308620.aspx
The question the other day was:
My code calls GetNumberFormat(“0”) and this returns “.00” on a zh-cn system and “0.00” on an English system. We take the pre-decimal portion of the string and end up with a null string in the zh-cn locale.
Are there flags to GetNumberFormat to control the output to be “0.00” irrespective of locale? Or should I just handle this in my code?
Ah, here's a tricky one for you.
On the one hand, there is LOCALE_ILZERO, which is clearly documented as
----------------------------------------------------------------------------
Specifier for leading zeros in decimal fields.
| Value | Meaning |
|---|---|
| 0 | No leading zeros |
| 1 | Leading zeros |
----------------------------------------------------------------------------
Now obviously one wants to respect locale preferences.
I mentioned this locale data field previously, in Ambiguity of Language in the Platform SDK and Objection, managed code! That zero is leading!.
On the other hand, in this case the decimal behavior is being widely ignored anyway.
And there is a NUMBERFMT.LeadingZero you can pass to GetNumberFormat or GetNumberFormatEx, which can be used to force the function to behave as requested.
Though keep in mind what those functions say about their lpNumberFormat parameter:
Pointer to a NUMBERFMT structure that contains number formatting information, with all members set to appropriate values. If the application does not set this parameter to NULL, the function uses the locale only for formatting information not specified in the structure, for example, the locale string value for the negative sign.
So yes, you can modify lpFormat->LeadingZero to make it 1, sure.
But you should also modify lpFormat->NumDigits to make it 0, under the circumstances.
You can probably ignore lpFormat->NegativeOrder and lpFormat->lpDecimalSep this time.
But if you don't specify several other members based off of GetLocaleInfo/GetLocaleInfoEx calls like lpFormat->lpThousandSep via LOCALE_STHOUSAND or lpFormat->Grouping via parsing of LOCALE_SGROUPING, then there isn't much point to calling a locale-specific function to format, anyway!
So the work here is definitely manageable, but may be more work then was originally hoped for....
Mihai on 23 May 2012 1:53 AM:
If there would only be a way to fill the NUMBERFMT structure with the default values...
Wait, there is :-)
mihai-nita.net/.../customized-getnumberformat-and-getcurrencyformat