Parsing doubles in vb.NET

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
For anyone having the same problem:
the solution:

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

Kind regards,
SL33PY
 
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,

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

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


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
 
SL33PY said:
For anyone having the same problem:
the solution:

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


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


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



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

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
 
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
 
Cor Ligthert said:
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.
Click to expand...

??
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
 
Cor Ligthert said:
Armin,


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

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

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
 
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,

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


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
 
Armin,
BTW, "the dot is the comma separator" is really nice. :-)
Click to expand...
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
 
Cor Ligthert said:
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.
Click to expand...

Well, but it's necessary to use a single, non-ambiguous format when
exchanging data in text files.
 
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.
 
Well, but it's necessary to use a single, non-ambiguous format when
exchanging data in text files.
Click to expand...
See my answer to Armin. It depends from what focus you are looking to the
problem.

Cor
 
Robson said:
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.
Click to expand...


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


Armin
 
Back
Top