Parsing doubles in vb.NET

[Armin Zingler]

Well the OP didn't say that

Right, he didn't. I assumed it because otherwise the was no reason that
the "." is used (because his culture uses the ",").


Armin

 

[Cor Ligthert [MVP]]

Robson,

The point I was making was that if you are attempting to read, say, a text
file generated using Norwegian culture, with the invariant culture
(English) on a Spanish PC, you can expect problems. You cannot be truely
culturally independant unless the data in this instance contains culture
information with it. Otherwise, you are restricted to only ever
reading/writing either with the invariant culture (ie. you the programmer
choose one and stick with it whereever you are in the world) or only ever
being able to read data from the same culture with which it was written,
which is also somewhat restrictive.

There are very few places where the culture information is needed extra to
add in your program while you still can use it in most places in the world.

However if you want to give a sample feel free (I know some).

Cor

 

[Robson]

I had this kind of problem recently: my software was installed by a
customer in Norway. Upon running the software he got the following
exception:

"20, 20 er en ugyldig verdi for Int32."

(20, 20 is not a valid value for Int32)

When he changed his language settings to EN, the exception did not occur
(this was the workaround until I could get him a bug fix). It turned out I
was using a version of MagicLibrary (for docking windows etc.) that did not
specify the language culture when reading/writing it's docking window layout
file. The default layout files I had created here at work were generated
with an EN culture. His version was reading the files in using the
Norwegian culture. I modified the Magic Library source to specify the EN
culture when loading and saving the layouts in order to fix the bug. Now
obviously this solution works in this case because the user never needs to
interact with the layout at that level, but in many other cases,
particularly where the user is able to input data according to his local
customs (any file format containing culturally specific string formats -
there are 1,000's of applications) and send files between different
cultures, it will not.

 

[Robson]

Well also to correct myself: you can have UI input with the local culture
and then behind the scenes you always convert to your neutral culture.
Load/Save with your neutral culture and then when UI displaying convert back
to the local culture. Then your data is always in a format the software can
work with without having to walk around with it's culture information
embedded in it.

 

[Cor Ligthert [MVP]]

Robson,

If you start to hard coding values outside your program or use them inside
your program as strings, than you are for sure in trouble.

However there are as well people who do things as multiplying by repeating
adding something and than saying that .Net is so slow.

In a normal way of use you don't often need the culture. (There where the
culture comes in, is as something is written in words as by instance the
months, or as there are currencysymbols used or calendars needed).

By instance about those calendars, the majority of the world uses the
Gregorian Calendar. (Not only the Christian cultures).

This is by instance not for a webpage, because a webpage cannot give the
Culture used on the system to the server, therefore is than an option to
give the pattern on the page that the user should use.

This does not say that the cultures are not used, in opposite, in my idea
you should as much keep your hands from it and only use when you are sure
that it is needed.

Cor

 

[Guest]

I think it is culture dependent.

Try this instead:

dim s as string

s = line.Substring(7, 8).Trim
currentImportDetail.Result = double.parse( _
s, System.Globalization.CultureInfo.InvariantCulture.NumberFormat) _
)



Armin

Wow look at all those replies. It took me a while to read them all.
The situation with the text file: it's generated by a scientific machine
(x-ray spectrometer) and it uses the dot as comma separator, indeed very
funny to read that

I thank you all for your contributions. I'm sorry for the late reply, but I
was working on some other things since I kind of "dirty fixed" it.

 

[Guest]

logical, if my string reads "0,06" it gives me 0.06 (just like it has to be)
the values have the same layout as in my initial post "0.006000" or
"123.456" etc