Re: CultureInfo.NumericFormat and System.Convert by dorminey
dorminey
Wed Aug 02 12:04:02 CDT 2006
Thanks for the help Nicole. Microsoft came through with the registry
setting this morning and we changed it. The interesting thing is that
we had found the setting before but it was blank on all the machines;
even the ones that didn't work. Microsoft support told us to set it to
"0" and then back to blank. We did so and the problem computers
magically worked. I can only think that .NET caches this info
somewhere and it was corrupted somehow.
I had been under the impression that in previous versions of the
framework this kind of information was kept in a separate place than
the OS. Even now I know that it will look in %WINNT%\Globalization for
.nlp files (even though it appears empty on our boxes currently).
However after playing with this registry setting and VS2003 I realize
that these settings have always been picked up from the registry.
I have in the past been concerned with culture settings when parsing
numbers containing decimal points or monetary sybols, etc.. I will be
more concerned about it in general after this experience. It would
seem that even when the culture of the target machines are a "given",
things can go wrong (though here we have more control than usual).
Nicole Calinoiu wrote:
> <dorminey@gmail.com> wrote in message
> news:1154447022.860236.308440@h48g2000cwc.googlegroups.com...
> > You have a valid point, however this particular application will be
> > highly controlled and the install will be regulated down to the
> > military grade hardware. The culture info of our OS is one of the
> > things we can take for granted. A flight engineer who decides to mess
> > with the culture settings would likely be reprimanded. The users who
> > are currently experiencing the problem didn't set this and would like
> > to know how to change it back to "+".
>
> That puts a very different spin on things... If the users didn't make the
> change deliberately, it's very likely that some rather impolite software
> changed the setting on their behalf.
>
>
> > At the moment I have no idea how to set the positiveSign property
> > outside of code and would love to find out how to do so.
>
> Assuming that the problem does lie in the regional settings, you should be
> able to change it back to an empty string by editing the sPositiveSign value
> under the HKEY_CURRENT_USER\Control Panel\International registry key.
>
>
>
> > I think that
> > 99.999% of coders would never have worried about this in the first
> > place. If it were even remotely common I would have found postings
> > about it already since parsing is a very common operation. Do you
> > commonly set the cultures on all of your threads?
>
> Yes, and I also use parsing method overloads that allow me to specify the
> culture settings explicitly. However, it's true that many folks don't, but
> they're probably not running into the same problem as you are given that
> setting "0" as the positive sign is likely to be rare.
>
>
>
> > I have no problem with the designers picking up a "0" as the positive
> > sign and running with it. I would do it too. But the user who figured
> > out how to set his positive sign property to zero would likely expect
> > strange behavior as "0" is universally a number in any culture using
> > arabic numerals (having just used the word arabic I've made sure
> > homeland security is now reading our thread. Hi guys). How would he
> > then express the concept of "nothing" mathematically? (or in your
> > example below, how would he express the concept of a single entity
> > mathematically if "1" were the positive sign?) If we were talking
> > about decimal point vs. comma, I could more easily see a problem.
> >
> > Anyway, I am still curious where this setting comes from and why in
> > "en-US" of all places, it is set to "0".
>
> If it is due to a regional settings modification, it's being picked up for
> en-US simply because that's the base culture for the current user's regional
> settings under Windows.
>
>
> >
> >
> > Nicole Calinoiu wrote:
> >> <dorminey@gmail.com> wrote in message
> >> news:1154440362.354067.162260@b28g2000cwb.googlegroups.com...
> >> > I'll give that a shot. However, it would be preferable if I didn't
> >> > have to set the culture of my threads manually in the first place.
> >> > Convert.ToDouble("0") should just work.
> >>
> >> Not really. Parsing is very culture-sensitive and, inconvenient as it
> >> may
> >> seem to you at the moment, the refusal of the .NET framework to parse a
> >> positive number sign that happens to be "0" to the value 0 is probably
> >> the
> >> best choice of behaviour the designers could have made. For example, if
> >> you
> >> happened to choose "1" as the positive number sign, what should the value
> >> "1" be parsed to?
> >>
> >>
> >> > I'd like to find out where I
> >> > can fix the problem with the machine or the .NET framework install that
> >> > is causing this.
> >>
> >> What makes you think there's necessarily a problem? If the users have
> >> adjusted their preferred positive sign, why would you want to muck about
> >> with it, particularly when adjusting your application's code to
> >> accomodate
> >> their preference takes very little effort.
> >>
> >>
> >>
> >> >
> >> > Nicole Calinoiu wrote:
> >> >> By default, when you create a new instance of a CultureInfo that
> >> >> matches
> >> >> the
> >> >> regional settings for the current user, any regional settings
> >> >> customizations
> >> >> will be copied to your new CultureInfo instance. If this is where
> >> >> your 0
> >> >> positive sign is originating, the problem can be avoided by using the
> >> >> CultureInfo constructor overload that allows you to specify that
> >> >> regional
> >> >> settings customizations should not be copied. e.g.:
> >> >>
> >> >> CultureInfo ci = new System.Globalization.CultureInfo("en-US", false);
> >> >>
> >> >>
> >> >>
> >> >> <dorminey@gmail.com> wrote in message
> >> >> news:1154375071.900845.181630@b28g2000cwb.googlegroups.com...
> >> >> >I am having a problem where a few machines at my company are failing
> >> >> >on
> >> >> > the following line of code:
> >> >> >
> >> >> > double dbl = System.Convert.ToDouble("0");
> >> >> >
> >> >> > I have traced it to the fact that for the thread's current culture
> >> >> > ("en-US") the NumberFormat.PositiveSign is in fact set to "0"
> >> >> > instead
> >> >> > of "+".
> >> >> >
> >> >> > In .net 1.1 there was a culture.nlp file where this info was stored
> >> >> > but
> >> >> > it has changed in 2.0. Where is this "0" for PositiveSign coming
> >> >> > from
> >> >> > and why is it defaulted to zero on a small minority of boxes at my
> >> >> > workplace? Below is a sample program that explains all. Thanks to
> >> >> > anyone who can help.
> >> >> >
> >> >> > using System;
> >> >> > using System.Collections.Generic;
> >> >> > using System.Text;
> >> >> > using System.Threading;
> >> >> > using System.Globalization;
> >> >> >
> >> >> > namespace ConsoleApplication10
> >> >> > {
> >> >> > class Program
> >> >> > {
> >> >> > static void Main(string[] args)
> >> >> > {
> >> >> > //this line fails on several machines at LockHeed
> >> >> > //it will work on most machines on which it is run
> >> >> > double dbl = Convert.ToDouble("0");
> >> >> >
> >> >> > //here we can reproduce the error we see on the problem
> >> >> > machines
> >> >> > CultureInfo ci = new
> >> >> > System.Globalization.CultureInfo("en-US");
> >> >> > ci.NumberFormat.PositiveSign = "0";
> >> >> >
> >> >> > Thread.CurrentThread.CurrentCulture = ci;
> >> >> >
> >> >> > dbl = Convert.ToDouble("0");
> >> >> >
> >> >> > //The problem we are seeing is that on the problem
> >> >> > machines
> >> >> > //the PositiveSign property is "0" by default instead of
> >> >> > the
> >> >> > //proper value of "+". The culture on these boxes is
> >> >> > "en-US".
> >> >> > }
> >> >> > }
> >> >> > }
> >> >> >
> >> >
> >