Parsing doubles in vb.NET

[SL33PY]

Hi,

I'm having a problem parsing strings (comming from a flat text input file)
to doubles.

the code:
currentImportDetail.Result = CType(line.Substring(7, 8).Trim(" "),
System.Double)

What is in my Watch:
line.Substring(7, 8).Trim(" ") "0.006000"
CType(line.Substring(7, 8).Trim(" "), System.Double) 6000.0
System.Decimal.Parse(line.Substring(7, 8).Trim(" ")) 6000D
cDec(line.Substring(7, 8).Trim(" ")) 6000D
cdbl(line.Substring(7, 8).Trim(" ")) 6000.0

I tried to use the other parse methods but for an unknown reason the result
is false and I don't know why.

My regional settings are currently Dutch(Belgium), but since he parses the
string to 6000 point 0 and not comma, I doubt that the regional settings are
the reason why it isn't parsing my data like I want.

[SL33PY]

For anyone having the same problem:
the solution:

try using : line.Substring(7, 8).Trim(" ").Replace(".",",")

Kind regards,
SL33PY

"SL33PY" wrote:

Hi,

I'm having a problem parsing strings (comming from a flat text input file)
to doubles.

the code:
currentImportDetail.Result = CType(line.Substring(7, 8).Trim(" "),
System.Double)

What is in my Watch:
line.Substring(7, 8).Trim(" ") "0.006000"
CType(line.Substring(7, 8).Trim(" "), System.Double) 6000.0
System.Decimal.Parse(line.Substring(7, 8).Trim(" ")) 6000D
cDec(line.Substring(7, 8).Trim(" ")) 6000D
cdbl(line.Substring(7, 8).Trim(" ")) 6000.0

I tried to use the other parse methods but for an unknown reason the result
is false and I don't know why.

My regional settings are currently Dutch(Belgium), but since he parses the
string to 6000 point 0 and not comma, I doubt that the regional settings are
the reason why it isn't parsing my data like I want.

[Robson]

Hold up a second, you are wanting to parse a double? (sorry if I
misunderstood),

You can:

Double.TryParse(theString)

or

Try

Double.Parse(theString)

Catch theException as SomeExceptionCantRemember

End Try
Hope this helps.

"SL33PY" <SL****@discussions.microsoft.com> wrote in message
news:B5**********************************@microsof t.com...

Hi,

I'm having a problem parsing strings (comming from a flat text input file)
to doubles.

the code:
currentImportDetail.Result = CType(line.Substring(7, 8).Trim(" "),
System.Double)

What is in my Watch:
line.Substring(7, 8).Trim(" ") "0.006000"
CType(line.Substring(7, 8).Trim(" "), System.Double) 6000.0
System.Decimal.Parse(line.Substring(7, 8).Trim(" ")) 6000D
cDec(line.Substring(7, 8).Trim(" ")) 6000D
cdbl(line.Substring(7, 8).Trim(" ")) 6000.0

I tried to use the other parse methods but for an unknown reason the
result
is false and I don't know why.

My regional settings are currently Dutch(Belgium), but since he parses the
string to 6000 point 0 and not comma, I doubt that the regional settings
are
the reason why it isn't parsing my data like I want.

[Cor Ligthert [MVP]]

Sl33PY,

Can you give us an idea what the string can looks like?

However, I see that you are using a string with a dot as comma seperator.

AFAIK, is that in the Dutch language for all three cultures a comma.

Dim dbl As Double = CDbl("abcd100,10".Substring(4, 5))

This gives for me 100.1

Cor

"SL33PY" <SL****@discussions.microsoft.com> schreef in bericht
news:B5**********************************@microsof t.com...

Hi,

I'm having a problem parsing strings (comming from a flat text input file)
to doubles.

the code:
currentImportDetail.Result = CType(line.Substring(7, 8).Trim(" "),
System.Double)

What is in my Watch:
line.Substring(7, 8).Trim(" ") "0.006000"
CType(line.Substring(7, 8).Trim(" "), System.Double) 6000.0
System.Decimal.Parse(line.Substring(7, 8).Trim(" ")) 6000D
cDec(line.Substring(7, 8).Trim(" ")) 6000D
cdbl(line.Substring(7, 8).Trim(" ")) 6000.0

I tried to use the other parse methods but for an unknown reason the
result
is false and I don't know why.

My regional settings are currently Dutch(Belgium), but since he parses the
string to 6000 point 0 and not comma, I doubt that the regional settings
are
the reason why it isn't parsing my data like I want.

[Armin Zingler]

"SL33PY" <SL****@discussions.microsoft.com> schrieb

Hi,

I'm having a problem parsing strings (comming from a flat text input
file) to doubles.

the code:
currentImportDetail.Result = CType(line.Substring(7, 8).Trim(" "),
System.Double)

What is in my Watch:
line.Substring(7, 8).Trim(" ") "0.006000"
CType(line.Substring(7, 8).Trim(" "), System.Double) 6000.0
System.Decimal.Parse(line.Substring(7, 8).Trim(" ")) 6000D
cDec(line.Substring(7, 8).Trim(" ")) 6000D
cdbl(line.Substring(7, 8).Trim(" ")) 6000.0

I tried to use the other parse methods but for an unknown reason the
result is false and I don't know why.

My regional settings are currently Dutch(Belgium), but since he
parses the string to 6000 point 0 and not comma,
What do you mean with this? The IDE always shows as ".", not a ",", no
matter where you live. This does not mean that it recognizes the "." as a
decimal separator.

I doubt that the
regional settings are the reason why it isn't parsing my data like I
want.

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

[Armin Zingler]

"SL33PY" <SL****@discussions.microsoft.com> schrieb

For anyone having the same problem:
the solution:

try using : line.Substring(7, 8).Trim(" ").Replace(".",",")

You know that this code doesn't work region independent? On a machine with
English regional settings, the code would fail because you rely on the
regional settings of the current machine whereas you have a region
independent setting (English) in the text file.
Armin

[Armin Zingler]

"Armin Zingler" <az*******@freenet.de> schrieb

"SL33PY" <SL****@discussions.microsoft.com> schrieb

For anyone having the same problem:
the solution:

try using : line.Substring(7, 8).Trim(" ").Replace(".",",")

You know that this code doesn't work region independent? On a
machine with English regional settings, the code would fail because
you rely on the regional settings of the current machine whereas you
have a region independent setting (English) in the text file.

Correction:
....you have a region *dependent* setting (English) in the text file.

Armin

[Cor Ligthert [MVP]]

Armin,

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

The InvariantCulture is the same culture as 'en-*' in my opinion not really
usefull here, it makes the program again culture dependend because in AFAIK
all English language cultures the dot is the comma seperator.

Cor

[Cor Ligthert [MVP]]

Armin,

With the same reply as you do it yourself, in this case it would work,
however that does the solution from the OP as well.

Cor

[Armin Zingler]

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb

Armin,

With the same reply as you do it yourself, in this case it would
work, however that does the solution from the OP as well.

??
The format in the text file is always English. InvariantCulture is always
English, too. Thus, it *always* works. The OP's solution not always works.
Armin

[Armin Zingler]

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb

Armin,

s = line.Substring(7, 8).Trim
currentImportDetail.Result = double.parse( _
s,
System.Globalization.CultureInfo.InvariantCulture. NumberFormat) _
)
The InvariantCulture is the same culture as 'en-*' in my opinion not
really usefull here, it makes the program again culture dependend

Yes, but it has to be culture dependend.
because in AFAIK all English language cultures the dot is the comma
seperator.

That's why InvariantCulture is useful because the text file always uses the
dot.

BTW, "the dot is the comma separator" is really nice. :-)
Armin

[Robson]

I don't think you can have it both ways. You can't ask the program to run
in many varied cultures and yet import correctly formats from different
cultures again. This numeric information, if it's being used
across-cultures, needs to carry it's culture around with it, so you can
choose the correct culture to use for parsing. Either that or as Armin
says, you need to standardize on the invariant culture whereever your
software is being used.

"Armin Zingler" <az*******@freenet.de> wrote in message
news:e6**************@TK2MSFTNGP11.phx.gbl...

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb

Armin,

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

The InvariantCulture is the same culture as 'en-*' in my opinion not
really usefull here, it makes the program again culture dependend

Yes, but it has to be culture dependend.

because in AFAIK all English language cultures the dot is the comma
seperator.

That's why InvariantCulture is useful because the text file always uses
the
dot.

BTW, "the dot is the comma separator" is really nice. :-)
Armin

[Cor Ligthert [MVP]]

Armin,

You are right, the OP solution will work in our cultures if it is either a
dot or a comma as decimal seperator.

The cultureInvariant will forever work if the dot is used (en-*) as decimal
separator in every culture.

Cor

[Armin Zingler]

"Robson" <no****@nomeansno.com> schrieb

I don't think you can have it both ways. You can't ask the program
to run in many varied cultures and yet import correctly formats from
different cultures again. This numeric information, if it's being
used
across-cultures, needs to carry it's culture around with it, so you
can choose the correct culture to use for parsing. Either that or
as Armin says, you need to standardize on the invariant culture
whereever your software is being used.

I'm not sure which posting you are referring to. I don't see a problem here:
The application can be region independent and still read region dependent
text files. For example, parsing input in textboxes can be done with
double.parse w/o an explicit culture information. This uses the current
culture and makes the application and it's usage culture independent. The
same application reads from a text file. As a programmer, you must know the
format of the numbers in the file. If you know that it is English, the
invariant culture should be used to parse the values.
Armin

[Herfried K. Wagner [MVP]]

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:

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

The InvariantCulture is the same culture as 'en-*' in my opinion not
really usefull here, it makes the program again culture dependend because
in AFAIK all English language cultures the dot is the comma seperator.

Well, but it's necessary to use a single, non-ambiguous format when
exchanging data in text files.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Cor Ligthert [MVP]]

Armin,

BTW, "the dot is the comma separator" is really nice. :-)

You are right I had really to laugh very much of my mistake.

Thanks for showing it to me.

(I made this as first, however, I forgot probably to click on send)

:-)

Cor

[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.
"Armin Zingler" <az*******@freenet.de> wrote in message
news:ur**************@TK2MSFTNGP10.phx.gbl...

"Robson" <no****@nomeansno.com> schrieb

I don't think you can have it both ways. You can't ask the program
to run in many varied cultures and yet import correctly formats from
different cultures again. This numeric information, if it's being
used
across-cultures, needs to carry it's culture around with it, so you
can choose the correct culture to use for parsing. Either that or
as Armin says, you need to standardize on the invariant culture
whereever your software is being used.

I'm not sure which posting you are referring to. I don't see a problem
here:
The application can be region independent and still read region dependent
text files. For example, parsing input in textboxes can be done with
double.parse w/o an explicit culture information. This uses the current
culture and makes the application and it's usage culture independent. The
same application reads from a text file. As a programmer, you must know
the format of the numbers in the file. If you know that it is English, the
invariant culture should be used to parse the values.
Armin

[Cor Ligthert [MVP]]

The InvariantCulture is the same culture as 'en-*' in my opinion not
really usefull here, it makes the program again culture dependend because
in AFAIK all English language cultures the dot is the comma seperator.

Well, but it's necessary to use a single, non-ambiguous format when
exchanging data in text files.

See my answer to Armin. It depends from what focus you are looking to the
problem.

Cor

[Armin Zingler]

"Robson" <no****@nomeansno.com> schrieb

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.

I assumed that the text file format is always English. I think that was the
OP's point.
Armin

[Robson]

Well the OP didn't say that ;)

"Armin Zingler" <az*******@freenet.de> wrote in message
news:OP*************@TK2MSFTNGP09.phx.gbl...

"Robson" <no****@nomeansno.com> schrieb

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.

I assumed that the text file format is always English. I think that was
the OP's point.
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

[Armin Zingler]

"Robson" <no****@nomeansno.com> schrieb im Newsbeitrag
news:dm*******************@news.demon.co.uk...

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

[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.
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:Oq**************@TK2MSFTNGP11.phx.gbl...

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]

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.

"Robson" <no****@nomeansno.com> wrote in message
news:dm*******************@news.demon.co.uk...

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.
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:Oq**************@TK2MSFTNGP11.phx.gbl...

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

[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


"Robson" <no****@nomeansno.com> schreef in bericht
news:dm*******************@news.demon.co.uk...

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.

"Robson" <no****@nomeansno.com> wrote in message
news:dm*******************@news.demon.co.uk...

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.
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:Oq**************@TK2MSFTNGP11.phx.gbl...

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

[SL33PY]

"Armin Zingler" wrote:

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.

[SL33PY]

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

"Cor Ligthert [MVP]" wrote:

Sl33PY,

Can you give us an idea what the string can looks like?

However, I see that you are using a string with a dot as comma seperator.

AFAIK, is that in the Dutch language for all three cultures a comma.

Dim dbl As Double = CDbl("abcd100,10".Substring(4, 5))

This gives for me 100.1

Cor

"SL33PY" <SL****@discussions.microsoft.com> schreef in bericht
news:B5**********************************@microsof t.com...

Hi,

I'm having a problem parsing strings (comming from a flat text input file)
to doubles.

the code:
currentImportDetail.Result = CType(line.Substring(7, 8).Trim(" "),
System.Double)

What is in my Watch:
line.Substring(7, 8).Trim(" ") "0.006000"
CType(line.Substring(7, 8).Trim(" "), System.Double) 6000.0
System.Decimal.Parse(line.Substring(7, 8).Trim(" ")) 6000D
cDec(line.Substring(7, 8).Trim(" ")) 6000D
cdbl(line.Substring(7, 8).Trim(" ")) 6000.0

I tried to use the other parse methods but for an unknown reason the
result
is false and I don't know why.

My regional settings are currently Dutch(Belgium), but since he parses the
string to 6000 point 0 and not comma, I doubt that the regional settings
are
the reason why it isn't parsing my data like I want.