by Michael S. Kaplan, published on 2007/06/02 16:51 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/06/02/3050031.aspx
(Sorry about the title, my long term watching of Law and Order once again impacts the blog!)
Some may remember from a few years back the Ambiguity of Language in the Platform SDK post which as far as I can remember is the only time I have ever talked about the LOCALE_ILZERO lctype value that one might pass to GetLocaleInfo. In fact, it seems like that post is the only time that it has come up across all of the blogs in blogs.msdn.com and blogs.technet.com.
I thought about when I was looking at the newsgroups, where Edward Diener asked over in microsoft.public.dotnet.internationalization:
In the control panel applet for Regional and Language Options, under Regional Options, in the Customize... dialog, Numbers tab, there is an option for Display Leading Zeros. This is a setting related to a particular culture ( which encapsulates a locale ID ) in dotnet, and a particular locale ID in WIN32.
This setting determines whether or not a leading zero should be displayed before the decimal point if the decimal number is greater than -1 and less than +1, ie. it has no whole number before the decimal point.
In Win32 this is equivalent to the Information Type of LOCALE_ILZERO for the GetLocaleInfo/SetLocalInfo functions.
In dotnet the equivalent class for finding cultural numeric information is the System.Globalization.CultureInfo class with its NumberFormat property of type NumberFormatInfo.
Yet I can find no equivalent property in NumberFormatInfo for getting or setting the Display Leading Zeros bool value for decimal numbers in a given culture.
Was this erroneously left out of the dotnet cultureinfo class structure, or is it someplace else where I have not found it ? If it is someplace else I would appreciate someone pointing it out to me where it is.
An interesting question, that.
And the answer? Well, in his question, the answer is the former -- this data item was left out of the managed world, and although the data is carried around inside of CultureInfo's data store for the sake of custom locales in Vista, it is never used by the .NET Framework. Just a field not added like some others were, for whatever reasons. I could speculate as to why, but for now we'll leave that aside, if that is okay.
Let's take some code and try formatting with the locales whose numbers have no leading zeroes:
using System;
using System.Globalization;
using System.Runtime.InteropServices;
namespace Testing {
class LeadingTest {
[DllImport("kernel32.dll", CharSet=CharSet.Unicode, ExactSpelling=true, SetLastError=true)]
private static extern int GetLocaleInfoW(int Locale, uint LCType, out int lpLCData, int cchData);
private const uint LOCALE_RETURN_NUMBER = 0x20000000; // return number instead of string
private const uint LOCALE_ILZERO = 0x00000012; // leading zeros for decimal
[STAThread]
static void Main(string[] args) {
foreach(CultureInfo ci in CultureInfo.GetCultures(CultureTypes.SpecificCultures)) {
int lpLCData;
if(GetLocaleInfoW(ci.LCID, LOCALE_ILZERO | LOCALE_RETURN_NUMBER, out lpLCData, 2) > 0) {
if(lpLCData == 0) {
float flt = 0.53f;
Console.WriteLine(ci.Name + " " + flt.ToString(ci));
}
}
}
}
}
}
Even running this code on Vista shows the five locales with this exoectation, only to see the expectation dashed:
he-IL 0.53
th-TH 0.53
vi-VN 0,53
zh-CN 0.53
uz-Cyrl-UZ 0,53
Damn, it just ain't having an impact, is it?.
But in Windows, it is, as you can see right in Regional and Language Options on one of those locales:
Thus my objection that the zero is leading here for managed code when it clearly shouldn't be....
This post brought to you by 0 (U+0030, a.k.a. DIGIT ZERO)
Gwyn on 2 Jun 2007 6:56 PM:
tslled? ITYM "talked". The keys are right, like next to each other ;)
Michael S. Kaplan on 2 Jun 2007 7:47 PM:
Whoops, fixed now. :-)
referenced by