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
From your message I get the idea that you have set some regional settings.
Can that be true?
And than which?
Cor
ru
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
> be the decimal symbol set to "," in the regional settings.
>
Is this meant as joke?
Cor
ru
No, why?
My client's decimal symbol was set to ",".
ru
Cor Ligthert
Probably in most systems in the world is the decimal point a ","
Cor
Cor Ligthert
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
@TK2MSFTNGP09.phx.gbl:
> 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/
Chad Z. Hower aka Kudzu
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
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
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
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
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
<cp...@hower.org> wrote:
>ru <u...@sx3all.be> wrote in news:6bg7b1pre165g7707...@4ax.com:
>> 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 .
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
news:10l8b1lc2uj5b0t6q...@4ax.com:
> 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.
ru
<cp...@hower.org> wrote:
>ru <u...@sx3all.be> wrote in
>news:10l8b1lc2uj5b0t6q...@4ax.com:
>> 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?
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.
>> 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'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.
>> 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.
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
news:j54ab1psolku95co5...@4ax.com:
>>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.
Yep, I thought that would do it. Definitely you should be using Parse methods instead of the cast
variants.
>>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.
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
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
@TK2MSFTNGP15.phx.gbl:
> 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/
Cor Ligthert
> @TK2MSFTNGP15.phx.gbl:
>> 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. :)
>
is wordier is it in my opinion a little bit more compatible.
:-)
Cor
Herfried K. Wagner [MVP]
>> 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. :)
No, it's not the same. 'Convert.ToInt32' will return 0 if 'Nothing' (a null
reference) is passed to it, 'Int32.Parse' will throw an exception.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Chad Z. Hower aka Kudzu
news:eFwACZP...@TK2MSFTNGP12.phx.gbl:
> (a null reference) is passed to it, 'Int32.Parse' will throw an
> exception.
Otherwise its identical. This oddity doesnt seem to be documented either and seems of limited use.
public static int ToInt32(string value);
Declaring Type: System.Convert
Assembly: mscorlib, Version=1.0.5000.0
public static int ToInt32(string value)
{
if (value == null)
{
return 0;
}
return int.Parse(value);
}
--
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/
ru
Hi Cor,
sorry for the delay, but I've been working through the weekend.
I did as you said, build the form in a new project, set the decimal
point to "," then ran the exe, and got the following error on the
Cint("1,00") code:
Additional information: The currency separator information specified
in the NumberFormatInfo is ambiguous for parsing.
If I use System.Convert.ToInt32("1,00") or Integer.Parse I get the
following error:
Additional information: Input string was not in a correct format.
Do you get the same results?
ru
Cor Ligthert
I don't have English settings, however I saw something strange when I
changed the decimal point in the showed config.
My question was what it does with a complete new application with only one
textbox.
A setting to of the config to comma and one CInt instruction. If that does
not work than you can call it in my opinon a bug.
I have the idea that it is not directly in Net because from what I saw in
that config. (After setting the decimal all showed values where changed
except one).
For me it is not impossible because of what I saw and what you told that it
is a bug in the OS or maybe even more possible one of the security or SP
updates, because you told that you did not have it before.
However, just a guess
Cor
pascal...@gmail.com
the problem itself was that they were not coherent (dot or comma was
irrelevant).
I had the SAME separator for both thousands and decimals in the Number
formatting pane. Therefore string to int cast was ambiguous. I suspect
the issue arises with money settings.
Pascal.
Cor Ligthert ha scritto: