425,529 Members | 1,826 Online
Need help? Post your question and get tips & solutions from a community of 425,529 IT Pros & Developers. It's quick & easy.

Coercion of a String Into a Double Doesnt work (??!!)

 P: n/a I've been scratching my head for weeks to understand why some code doesnt work for me. here is what i have: dim sVal as string = "13.2401516" dim x as double x = sVal debug.writeline ( x) Now on my system (English WinXp proSP3) the debug line is as follows 13.2401516 However, when a user in a different locale (different localized version of Windows) the debug line prints 132401516 The same number only without the decimal. Can anyone shed some light on why this happanes? is it because the user may have a different format for numbers and the coercion is done according to that format? How can i ensure that i get the proper conversion? AGP Aug 25 '08 #1
9 Replies

 P: n/a Hi AGP, The reason is in some locales the . is used as a thousands separator much like how , is used in others, e.g 1,000 is the same as 1.000 depending on the locale. To take explicit control of how the Double is parsed used the double Parse method, e.g: x = Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo) "AGP"

 P: n/a AGP, Be aware that you should avoid hard coded decimimal pointers However, that is impossiblie in a document or a webpage. Have therefore a look at this. http://www.vb-tips.com/Cultures.aspx Cor "AGP"

 P: n/a The data that i am reading will be non-locale specific and will always be written as pure decimal. Example 13.58 is read as 13 and 58 hundreths. So if I read your link properly then I should just coerce the string before assiging it and that should give me a pure decimal number as follows: dim sVal as string = "13.2401516" dim x as double x = CDbl( sVal ) AGP "Cor Ligthert [MVP]" I've been scratching my head for weeks to understand why some code doesntwork for me.here is what i have:dim sVal as string = "13.2401516"dim x as doublex = sValdebug.writeline ( x)Now on my system (English WinXp proSP3) the debug lineis as follows13.2401516However, when a user in a different locale (different localized versionof Windows) the debug line prints132401516The same number only without the decimal. Can anyone shed some light onwhy this happanes? is it because the user may have adifferent format for numbers and the coercion is done according to thatformat? How can i ensure that i get the proper conversion? AGP Aug 26 '08 #4

 P: n/a Im using VS2005 and noticed that secondary option doesnt come up by default so what is the difference between Double.Parse(sVal, Globalization.NumberStyles.Float) and Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo) AGP "Bill McCarthy" I've been scratching my head for weeks to understand why some code doesntwork for me.here is what i have:dim sVal as string = "13.2401516"dim x as doublex = sValdebug.writeline ( x)Now on my system (English WinXp proSP3) the debug lineis as follows13.2401516However, when a user in a different locale (different localized versionof Windows) the debug line prints132401516The same number only without the decimal. Can anyone shed some light onwhy this happanes? is it because the user may have adifferent format for numbers and the coercion is done according to thatformat? How can i ensure that i get the proper conversion? AGP Aug 26 '08 #5

 P: n/a AGP wrote: Im using VS2005 and noticed that secondary option doesnt come up by default The double.Parse method has an overload that takes an IFormatProvider. You can use any class that implements that interface, including NumberFormatInfo, but you won't get a complete list of those classes in the intellisense. so what is the difference between Double.Parse(sVal, Globalization.NumberStyles.Float) and Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo) AGP The difference is that the first one still uses the default culture, which may not use a period as decimal separator. The InvariantInfo is culture independent and a period has been chosen as it's decimal separator. -- Göran Andersson _____ http://www.guffa.com Aug 26 '08 #6

 P: n/a ok here is what i have dim sVal1 as string = "13.2401516" dim sVal2 as string = "53.2168183" a = CDbl(sVal1) b = Double.Parse(sVal2, Globalization.NumberFormatInfo.InvariantInfo) and the debug line from the user 132401516 53,2168183 He is using a German Windows XP version. In that locale the number 1300 and 24/100 would be written 1300,24 so it seems to me that the second is the correct way to writre it as suggested. Double.Parse(sVal2, Globalization.NumberFormatInfo.InvariantInfo) seems to correctly interpret the number. But my question is...that is how the user sees the number that is calculated but internally is it still 53 and 2168183/10000000? In other words, if i pump that value to another process will it still be seen as 53 and 2168183/10000000? Im going to install the German MUI and do some testing here but i think Im learning something that I never paid much attention to in the past. AGP "Göran Andersson" Im using VS2005 and noticed that secondary option doesnt come up bydefault The double.Parse method has an overload that takes an IFormatProvider. You can use any class that implements that interface, including NumberFormatInfo, but you won't get a complete list of those classes in the intellisense. >so what is the difference betweenDouble.Parse(sVal, Globalization.NumberStyles.Float)andDouble.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)AGP The difference is that the first one still uses the default culture, which may not use a period as decimal separator. The InvariantInfo is culture independent and a period has been chosen as it's decimal separator. -- Göran Andersson _____ http://www.guffa.com Aug 27 '08 #7

 P: n/a Pure, Pure decimal, only 2% of the world population is using the dot as decimal seperator, the rest is using a comma. Even in at least one country where English is used is the comma the decimal seperator. Cor "AGP" AGP,Be aware that you should avoid hard coded decimimal pointersHowever, that is impossiblie in a document or a webpage.Have therefore a look at this.http://www.vb-tips.com/Cultures.aspxCor"AGP" >I've been scratching my head for weeks to understand why some codedoesnt work for me.here is what i have:dim sVal as string = "13.2401516"dim x as doublex = sValdebug.writeline ( x)Now on my system (English WinXp proSP3) the debug lineis as follows13.2401516However, when a user in a different locale (different localized versionof Windows) the debug line prints132401516The same number only without the decimal. Can anyone shed some light onwhy this happanes? is it because the user may have adifferent format for numbers and the coercion is done according to thatformat? How can i ensure that i get the proper conversion? AGP Aug 27 '08 #8

 P: n/a Cor Ligthert[MVP] wrote: Pure decimal, only 2% of the world population is using the dot as decimal seperator, the rest is using a comma. Cite? I present to you the countries of China and India, which I suggest between them make up somewhat more than 2% of the world's population ;-) http://en.wikipedia.org/wiki/Decimal_separator Andrew Aug 27 '08 #9

 P: n/a Suggest y'all use TryParse() rather than Parse(). The former will return a zero value if the input is bad whereas TryParse() will return a zero value but not throw an exception. -bwr- "AGP" AGP wrote: >>Im using VS2005 and noticed that secondary option doesnt come up bydefault The double.Parse method has an overload that takes an IFormatProvider.You can use any class that implements that interface, includingNumberFormatInfo, but you won't get a complete list of those classes inthe intellisense. >>so what is the difference betweenDouble.Parse(sVal, Globalization.NumberStyles.Float)andDouble.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)AGP The difference is that the first one still uses the default culture,which may not use a period as decimal separator. The InvariantInfo isculture independent and a period has been chosen as it's decimalseparator.--Göran Andersson_____http://www.guffa.com Aug 29 '08 #10