|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
CultureInfo.NumericFormat and System.Convertthe 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". } } } 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); <dormi***@gmail.com> wrote in message Show quoteHide quote 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". > } > } > } > 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. I'd like to find out where I can fix the problem with the machine or the .NET framework install that is causing this. Nicole Calinoiu wrote: Show quoteHide quote > 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); > > > > <dormi***@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". > > } > > } > > } > > <dormi***@gmail.com> wrote in message
news:1154440362.354067.162260@b28g2000cwb.googlegroups.com... Not really. Parsing is very culture-sensitive and, inconvenient as it may > 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. 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 What makes you think there's necessarily a problem? If the users have > can fix the problem with the machine or the .NET framework install that > is causing this. 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. Show quoteHide quote > > 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); >> >> >> >> <dormi***@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". >> > } >> > } >> > } >> > > 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 "+". 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. 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? 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". Nicole Calinoiu wrote: Show quoteHide quote > <dormi***@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); > >> > >> > >> > >> <dormi***@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". > >> > } > >> > } > >> > } > >> > > > <dormi***@gmail.com> wrote in message
news:1154447022.860236.308440@h48g2000cwc.googlegroups.com... That puts a very different spin on things... If the users didn't make the > 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 "+". 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 Assuming that the problem does lie in the regional settings, you should be > outside of code and would love to find out how to do so. 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 Yes, and I also use parsing method overloads that allow me to specify the > 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? 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 If it is due to a regional settings modification, it's being picked up for > 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". en-US simply because that's the base culture for the current user's regional settings under Windows. Show quoteHide quote > > > Nicole Calinoiu wrote: >> <dormi***@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); >> >> >> >> >> >> >> >> <dormi***@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". >> >> > } >> >> > } >> >> > } >> >> > >> > > 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: Show quoteHide quote > <dormi***@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: > >> <dormi***@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); > >> >> > >> >> > >> >> > >> >> <dormi***@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". > >> >> > } > >> >> > } > >> >> > } > >> >> > > >> > > > Just to throw my $.02 in, be aware of the fact that $0.02 will fail when
passed to Double.TryParse. See http://devauthority.com/blogs/jwooley/archive/2006/03/15/788.aspx for details on how to work around this. Jim Wooley http://devauthority.com/blogs/jwooley/default.aspx Show quoteHide quote > <dormi***@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.  
Other interesting topics
Unhandled Exception in Windows Service
Intra-thread lock Launching and Monitoring Executables aspnet user Where is the parameter argument collection? .NET 2.0 Enterprise Library 2.0 installation problem Using IPC question: one process as IPC client and server at same time problem. communicate between two exe applications Testing for invalid characters when creating a directory? |
|||||||||||||||||||||||
