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

  • Thread starter Thread starter AGP
  • Start date Start date
A

AGP

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
 
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)
 
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
 
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
 
AGP said:
Im using VS2005 and noticed that secondary option doesnt come up by default
Click to expand...

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
Click to expand...

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.
 
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
 
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
 
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 said:
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
Click to expand...
 
Back
Top