Local Settings and NumberFormat issues

[ru]

I got an error message from a client running my software, and after
building a test machine with the exact regional settings as my client
I could reproduce the bug. The setting causing the bug turned out to
be the decimal symbol set to ",".

The error message was: "The currency separator information specified
in the NumberFormatInfo is ambiguous for parsing."

The code causing the error was a simple one:
int100 = CInt(txt100.Text)

int100 is an integer
txt100 is a textbox displaying an integer variable: there's no decimal
separator involved, so I don't know why this is raising an error.

Changing the code to:
int100 = Integer.Parse(txt100History.Text,
NumberStyles.AllowDecimalPoint)
cleared the error.

Another thing I discovered was that the IsNumeric function also didn't
work properly. The following code would always return false, no matter
what key was pressed:

Private Sub txtScore_TextChanged(ByVal sender As Object, ByVal e As
System.EventArgs) Handles txtScore.TextChanged
If IsNumeric(txtScore.Text) = False Then
txtScore.Text = ""
End If
'End Sub

Can someone explain why the errors were thrown, eventhough no decimal
separators were involved? And also, what's the best way in dealing
with different regional settings?

Thanks,
ru

 

[Cor Ligthert]

Ru,

From your message I get the idea that you have set some regional settings.

Can that be true?

And than which?

Cor

 

[ru]

Ru,

From your message I get the idea that you have set some regional settings.

Can that be true?

And than which?

Cor

Hi Cor,

like I said in the original message:
The setting causing the bug turned out to
be the decimal symbol set to "," in the regional settings.

ru

 

[Cor Ligthert]

Ru,

be the decimal symbol set to "," in the regional settings.

Is this meant as joke?

Cor

 

[ru]

Ru,

Is this meant as joke?

Cor

No, why?

My client's decimal symbol was set to ",".

ru

 

[Cor Ligthert]

Ru,

Probably in most systems in the world is the decimal point a ","

Cor

 

[Chad Z. Hower aka Kudzu]

Probably in most systems in the world is the decimal point a ","

Well yes and no. Much of Europe as you know uses , for the decimal point and . for the thousands
separator. Now Im not sure about China and India - but if they do then just accounting for population
alone Id say that most of the world does not.

What really goofs me up is dates. Europe uses d/m while North America uses m/d. So when you
have something like 21/4 its easy to know the actual date. But when you have someting like 6/8... Aug
6th or June 8th?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/

 

[Cor Ligthert]

Kudzu,

I have no idea how it is in Asia (beside Russia), but how about South and
Middle America (Where is spoken Spanish and Portugese and in very small
parts French, English and Dutch), Africa (Important parts speaks beside
Arabian and own lanugages French and because their colonial background do
numbers probably as the Portugese). (I am curious what in South Africa is
used).

So maybe I would have written countries which use for centurys the arabian
characters for numbers an have not as own language English.

About dates and times, from the English speaking countries I am only sure
from the USA and English speaking Canada that they use MM-dd-yy. PM and AM
is everywhere in English speaking countries. For the rest I thought it was
accoording what I wrote above about the used characters dd-MM-yy.

When I wrote once in past about this, there was somebody, who ws answering
from Australia that this was the reason they would never buy typical USA
software anymore.

However al as far as I know.

Cor

 

[Chad Z. Hower aka Kudzu]

I have no idea how it is in Asia (beside Russia), but how about South

Russia very often uses , for decimals and . for thousands. (As your probably know I live in
Russia half the year). Im not sure which European countries do as well, but in my travels I see it
a lot.

So maybe I would have written countries which use for centurys the
arabian characters for numbers an have not as own language English.

Its not juts arabic numbers (Which are actually Hindi numbers). I have "Arabic" numbers as most
refer them to on my system. I got used to them in when I worked in the middle east and just left
them.

About dates and times, from the English speaking countries I am only
sure from the USA and English speaking Canada that they use MM-dd-yy.
PM and AM is everywhere in English speaking countries. For the rest I
thought it was accoording what I wrote above about the used characters
dd-MM-yy.

For the most part yes. But the US thinks the whole world uses mm/dd.

When I wrote once in past about this, there was somebody, who ws
answering from Australia that this was the reason they would never buy
typical USA software anymore.

Quicken is a good example of this. It cannot handle the dates as it does not use the system
settings. ;(


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

 

[ru]

Ru,

Probably in most systems in the world is the decimal point a ","

Cor

I know, but when I change it back to "." the problems disappear. This
is a Windows XP Pro Dutch system with SP2. Any ideas as to why this
may happen?

ru

 

[Cor Ligthert]

Kudzu,

Some things are easy to find in Wikipedia

http://en.wikipedia.org/wiki/Decimal_separator

This shows as I always write. Beside the original English speaking countries
is the dot as well extremely used as decimal point separator, in what I call
forever Coca-Cola cultures. (Cultures that don't have original the Latin and
Arabian characters in there main writing system).

Beside that we see that countries, long time cultural dominated by foreing
countries, use the ones from those. By instance India(England) has a dot
seperator, while Indonesia has a comma seperator (Holland). In addition we
see that South Africa uses the Dutch system while the official language is
English.

In correction of my previous message do I see now that Middle America uses
the dot.

I find this forever interresting stuff. As you see do I like history.

Cor

 

[Cor Ligthert]

Ru,

I am Dutch and I know that in our country as well Dutch as English operating
systems are used.

However if you want to use the comma separator on an English system than
you can change (not advisable) the settings of that. Because English systems
are more and more only servers is that mostly not important (as I wrote not
advisable), admins use automatically the dot when that is needed on those
servers, that is in my opinion the case for most Dutch users of English
operating systems (used in International environments) .

I have not much experience where this change of settings can go wrong. One
situation I know for sure, which is W98/Me. Setting the culture setting on
those systems has no sense for dotNet. In W98/Me you have to change the
keyboard parameters for that (An old expirience I don't know if that is
changed with latest service packs).

I hope this gives some help. However some more information from you, than
some words in a message would probably give the ones who want to help you
more change to do that.

My question was, did you use culture settings in your program(s), I have not
seen any answer on that.

I hope this helps,

Cor

 

[ru]

Ru,

I am Dutch and I know that in our country as well Dutch as English operating
systems are used.

However if you want to use the comma separator on an English system than
you can change (not advisable) the settings of that. Because English systems
are more and more only servers is that mostly not important (as I wrote not
advisable), admins use automatically the dot when that is needed on those
servers, that is in my opinion the case for most Dutch users of English
operating systems (used in International environments) .

I have not much experience where this change of settings can go wrong. One
situation I know for sure, which is W98/Me. Setting the culture setting on
those systems has no sense for dotNet. In W98/Me you have to change the
keyboard parameters for that (An old expirience I don't know if that is
changed with latest service packs).

I hope this gives some help. However some more information from you, than
some words in a message would probably give the ones who want to help you
more change to do that.

My question was, did you use culture settings in your program(s), I have not
seen any answer on that.

I hope this helps,

Cor

Hi Cor,

the only culture settings I use is like this:
Dim strDateFormat As String =
CultureInfo.CurrentCulture.DateTimeFormat.CurrentInfo.ShortDatePattern.ToString

to format Dates to the users system.
But that code is independent of the CInt code.

btw, I just tested my system, which is an English/US box with XP Pro
SP2, and when I change the "." to "," my program also crashes.
I never had this before, I know because I tested it a couple of months
back. Very weird.

ru

 

[Chad Z. Hower aka Kudzu]

I know, but when I change it back to "." the problems disappear. This
is a Windows XP Pro Dutch system with SP2. Any ideas as to why this
may happen?

I didnt see the original message, but its usually caused by software not using system routines for
parsing and hard coding to the .


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/

 

[ru]

I didnt see the original message, but its usually caused by software not using system routines for
parsing and hard coding to the .

I'm not aware of bypassing the system routines for parsing - how does
one do that Can you give me an example?

The code causing my problem is pretty basic stuff:

int100 = CInt(txt100.Text)

int100 is an integer
txt100 is a textbox displaying an integer variable: there's no decimal
separator involved, so I don't know why this is raising an error.

Changing the code to:
int100 = Integer.Parse(txt100History.Text,
NumberStyles.AllowDecimalPoint)
cleared the error.

Another thing I discovered was that the IsNumeric function also didn't
work properly. The following code would always return false, no matter
what key was pressed:

Private Sub txtScore_TextChanged(ByVal sender As Object, ByVal e As
System.EventArgs) Handles txtScore.TextChanged
If IsNumeric(txtScore.Text) = False Then
txtScore.Text = ""
End If
'End Sub

I now notice that only parsing of variables from the form itself,
displayed by labels or textboxes, is causing troubles. I just tested a
conversion from an integer declared in code to a double to a string
without errors.

ru

 

[Chad Z. Hower aka Kudzu]

I'm not aware of bypassing the system routines for parsing - how does
one do that Can you give me an example?

Developers often write their own parsing routines, especially on non .NET platforms where the
frameworks may not support it, or worse yet the frameworks rely on configurations from the
developer and ignore the system settings.

int100 = CInt(txt100.Text)

int100 is an integer
txt100 is a textbox displaying an integer variable: there's no decimal
separator involved, so I don't know why this is raising an error.

Im more of a C# person than a VB person although before Delphi I used to do a lot of VB and
even wrote for many magizines. CInt I know is a type of VB.NET cast but under the hood I dont
remember what its C# equivalent is, IIRC its more equivalent to an implicit cast in VB.NET than a
parse. Generally I would recommend against these and prefer the parse methods.

Does it have a thousands separator in it possibly?

Changing the code to:
int100 = Integer.Parse(txt100History.Text,
NumberStyles.AllowDecimalPoint)
cleared the error.

Does just Parse(txt100History.Text) work for you or must you specify the second argument? What
is the exact string value of txt100Histor.Text when the exception is thrown?

Another thing I discovered was that the IsNumeric function also didn't
work properly. The following code would always return false, no matter
what key was pressed:

Private Sub txtScore_TextChanged(ByVal sender As Object, ByVal e As
System.EventArgs) Handles txtScore.TextChanged
If IsNumeric(txtScore.Text) = False Then
txtScore.Text = ""
End If
'End Sub

Isnt IsNumeric one of the old VB comptability routines? Generally speaking you should avoid
using these in new code and rely on FCL functionality instead. And is it possible that IsNumeric
only checks the first character in the string? I seem to remember something about this from the
long ago VB days.

I now notice that only parsing of variables from the form itself,
displayed by labels or textboxes, is causing troubles. I just tested a
conversion from an integer declared in code to a double to a string
without errors.

Quite possibly because when you are dispalying it, regional settings are formatting it. Then when
you are rereading it, its formatted.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/

 

[ru]

Developers often write their own parsing routines, especially on non .NET platforms where the
frameworks may not support it, or worse yet the frameworks rely on configurations from the
developer and ignore the system settings.


Im more of a C# person than a VB person although before Delphi I used to do a lot of VB and
even wrote for many magizines. CInt I know is a type of VB.NET cast but under the hood I dont
remember what its C# equivalent is, IIRC its more equivalent to an implicit cast in VB.NET than a
parse. Generally I would recommend against these and prefer the parse methods.

Does it have a thousands separator in it possibly?


Does just Parse(txt100History.Text) work for you or must you specify the second argument? What
is the exact string value of txt100Histor.Text when the exception is thrown?

Wow, removing the second argument works like a charm. I use CInt and
CDbl quite a lot, so I guess I'll have to change my habits.

Isnt IsNumeric one of the old VB comptability routines? Generally speaking you should avoid
using these in new code and rely on FCL functionality instead. And is it possible that IsNumeric
only checks the first character in the string? I seem to remember something about this from the
long ago VB days.

I've changed the IsNumeric function to the following code:
Private Sub txtScore_KeyPress(ByVal sender As Object, ByVal e As
System.Windows.Forms.KeyPressEventArgs) Handles txtScore.KeyPress
If e.KeyChar < "0" Or e.KeyChar > "9" Then
If (e.KeyChar = Chr(&H8)) Or (e.KeyChar = "Keys.Delete")
Then
Else
e.Handled = True
End If
End If
End Sub

This works, and is also more accurate in handling user input.

Quite possibly because when you are dispalying it, regional settings are formatting it. Then when
you are rereading it, its formatted.

Thanks for your insight, these errors were really getting on my
nerves. I shall lose the old VB code where I can. And to think I've
never coded in classic VB, I can only imagine what oldtimers must go
through.

ru

 

[Chad Z. Hower aka Kudzu]

Wow, removing the second argument works like a charm. I use CInt and
CDbl quite a lot, so I guess I'll have to change my habits.

Yep, I thought that would do it. Definitely you should be using Parse methods instead of the cast
variants.

Thanks for your insight, these errors were really getting on my
nerves. I shall lose the old VB code where I can. And to think I've
never coded in classic VB, I can only imagine what oldtimers must go
through.

Its a big change for VB developers. But regional settings can be troubling too. I just know them very
well because Ive lived in several parts of the world and travel quite a bit. I have an English-
Russian-Greek-Arabic machine right now with Canadian regional settings.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Get your ASP.NET in gear with IntraWeb!
http://www.atozed.com/IntraWeb/

 

[Cor Ligthert]

Ru,

I find the CInt an extremly strong instrucion.

Can you try this.
Set your decimal point to comma.
Have a look if it is done for everything
Create a new form
Drag a textbox on the form
Click on the form and set in than in the loadevent

dim whatever as integer = Cint("1,00")

For me the most compatible in system is this one
System.Convert.ToInt32("1,00")

However Cint should do it and is less typing.

I am interested in the result.

Cor

 

[Chad Z. Hower aka Kudzu]

For me the most compatible in system is this one
System.Convert.ToInt32("1,00")

Thats the same as Int32.Parse AFAIk, just a bit wordier.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/