Parsing doubles in vb.NET

[Cor Ligthert [MVP]]

Re: Parsing doubles in vb.NET

Armin,[color=blue]
>
> BTW, "the dot is the comma separator" is really nice. :-)
>[/color]
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]

Re: Parsing doubles in vb.NET

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.nospam@free net.de> wrote in message
news:urOyILN9FH A.2844@TK2MSFTN GP10.phx.gbl...[color=blue]
> "Robson" <nonono@nomeans no.com> schrieb[color=green]
>> 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.[/color]
>
>
> 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
>[/color]

[Cor Ligthert [MVP]]

Re: Parsing doubles in vb.NET

[color=blue][color=green]
>> The InvariantCultur e 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.[/color]
>
> Well, but it's necessary to use a single, non-ambiguous format when
> exchanging data in text files.
>[/color]
See my answer to Armin. It depends from what focus you are looking to the
problem.

Cor

[Armin Zingler]

Re: Parsing doubles in vb.NET

"Robson" <nonono@nomeans no.com> schrieb[color=blue]
> 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.[/color]


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


Armin

[Robson]

Re: Parsing doubles in vb.NET

Well the OP didn't say that ;)

"Armin Zingler" <az.nospam@free net.de> wrote in message
news:OPIQ6BO9FH A.340@TK2MSFTNG P09.phx.gbl...[color=blue]
> "Robson" <nonono@nomeans no.com> schrieb[color=green]
>> 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.[/color]
>
>
> I assumed that the text file format is always English. I think that was
> the OP's point.
>
>
> Armin[/color]

[Cor Ligthert [MVP]]

Re: Parsing doubles in vb.NET

Robson,
[color=blue]
> 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.
>[/color]

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]

Re: Parsing doubles in vb.NET

"Robson" <nonono@nomeans no.com> schrieb im Newsbeitrag
news:dmhirm$e6j $1$830fa7a5@new s.demon.co.uk.. .[color=blue]
> Well the OP didn't say that ;)[/color]

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


Armin

[Robson]

Re: Parsing doubles in vb.NET

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]" <notmyfirstname @planet.nl> wrote in message
news:OqBEtVO9FH A.1028@TK2MSFTN GP11.phx.gbl...[color=blue]
> Robson,
>[color=green]
>> 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.
>>[/color]
>
> 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
>
>
>[/color]

[Robson]

Re: Parsing doubles in vb.NET

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" <nonono@nomeans no.com> wrote in message
news:dmhle5$71g $1$8302bc10@new s.demon.co.uk.. .[color=blue]
>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]" <notmyfirstname @planet.nl> wrote in message
> news:OqBEtVO9FH A.1028@TK2MSFTN GP11.phx.gbl...[color=green]
>> Robson,
>>[color=darkred]
>>> 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.
>>>[/color]
>>
>> 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
>>
>>
>>[/color]
>
>[/color]

[Cor Ligthert [MVP]]

Re: Parsing doubles in vb.NET

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" <nonono@nomeans no.com> schreef in bericht
news:dmhn5h$f54 $1$830fa7a5@new s.demon.co.uk.. .[color=blue]
> 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" <nonono@nomeans no.com> wrote in message
> news:dmhle5$71g $1$8302bc10@new s.demon.co.uk.. .[color=green]
>>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]" <notmyfirstname @planet.nl> wrote in message
>> news:OqBEtVO9FH A.1028@TK2MSFTN GP11.phx.gbl...[color=darkred]
>>> 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
>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[SL33PY]

Re: Parsing doubles in vb.NET

"Armin Zingler" wrote:
[color=blue]
>
> I think it is culture dependent.
>
> Try this instead:
>
> dim s as string
>
> s = line.Substring( 7, 8).Trim
> currentImportDe tail.Result = double.parse( _
> s, System.Globaliz ation.CultureIn fo.InvariantCul ture.NumberForm at) _
> )
>
>
>
> Armin
>
>[/color]

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]

Re: Parsing doubles in vb.NET

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:
[color=blue]
> 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,1 0".Substring (4, 5))
>
> This gives for me 100.1
>
> Cor
>
> "SL33PY" <SL33PY@discuss ions.microsoft. com> schreef in bericht
> news:B578AD49-A36D-451B-883D-FC2244935186@mi crosoft.com...[color=green]
> > Hi,
> >
> > I'm having a problem parsing strings (comming from a flat text input file)
> > to doubles.
> >
> > the code:
> > currentImportDe tail.Result = CType(line.Subs tring(7, 8).Trim(" "),
> > System.Double)
> >
> > What is in my Watch:
> > line.Substring( 7, 8).Trim(" ") "0.006000"
> > CType(line.Subs tring(7, 8).Trim(" "), System.Double) 6000.0
> > System.Decimal. Parse(line.Subs tring(7, 8).Trim(" ")) 6000D
> > cDec(line.Subst ring(7, 8).Trim(" ")) 6000D
> > cdbl(line.Subst ring(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.
> >[/color]
>
>
>[/color]