I have no idea what the problem could be and am looking for ideas.
Could you post a short but complete program which demonstrates the
problem?
See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:MPG.2057e11a6...@msnews.microsoft.com...
Can you produce a short but complete program that fails on that single
machine? (A console app would be easiest.)
It does sound very odd...
This almost smells like a culture-conversion type of problem. But
converting a string that only contains an integer number (and a small
integer number at that) to an int16? How can that fail? But I've been
Googling and it appears others have experienced it as well. Not sure about
an easy fix yet though.
"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:MPG.2057fc12c...@msnews.microsoft.com...
This sounds similar to a problem I saw a few months ago:
"Convert.ToInt32("0") throws an exception, some systems"
http://groups.google.com/group/microsoft.public.dotnet.framework/browse_frm/thread/1e2a5a340425a67b/9eb8e300c7c60821
I filed a bug with Microsoft; they're not able to reproduce it. You
might want to post some details in that bug report:
https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=253265&wa=wsignin1.0&siteid=210
Michael
<mpet...@gmail.com> wrote in message
news:1173233099....@v33g2000cwv.googlegroups.com...
"Jen" <no...@nowhere.com> wrote in message
news:%233ZUVgC...@TK2MSFTNGP06.phx.gbl...
"Jen" <no...@nowhere.com> ha scritto nel messaggio
news:%233ZUVgC...@TK2MSFTNGP06.phx.gbl...
What the code is doing is it's taking a string from a TextBox that is part
of a User Control and converting it to a short. The exception's trace looks
something like this:
System.Number.StringToNumber()
System.Number.ParseInt32()
System.Number.Int16.Parse()
Util.IPAddressBox.get_Octet3() <-- this is an Int16 property in my user
control
I'm not sure why the call to ParseInt32 is there but I guess that's the way
it works. I've also seen the exception happen with textboxes that convert
right to Int32 instead of Int16. They are also accessed through a property
of a user control.
I am having the guy that owns the machine try the "set locale to something
else then back again to English (US)" trick that someone mentioned to see if
that fixes it. If it does not I'll pursue additional debugging.
"Laura T." <L...@NOWHERE.COM> wrote in message
news:eKdCTEL...@TK2MSFTNGP06.phx.gbl...
"Laura T." <L...@NOWHERE.COM> wrote in message
news:ekmChRMY...@TK2MSFTNGP03.phx.gbl...
> Yes, internally ToXX use parse to get the number.
> Just for curiosity I attach a .txt file here containing the code for the
> convert path that can raise the format exception.
> Reading it, it seems that only bad input data could trigger the exception,
> but...
>
>
> "Jen" <no...@nowhere.com> ha scritto nel messaggio
> news:ucjHptLY...@TK2MSFTNGP03.phx.gbl...
"Jen" <no...@nowhere.com> wrote in message
news:ucjHptLY...@TK2MSFTNGP03.phx.gbl...
FWIW, I have another machine exhibiting this problem, and I've been
emailing back and forth with the class library team about it. They're
trying to debug it when neither I nor MS has physical access to the
machine. Not easy.
Michael
For reference, here's what we found. The affected machine had bad
data for the registry value [HKEY_CURRENT_USER\Control Panel
\International\sPositiveSign]. Normally, this value is an empty
REG_SZ (null-terminated string). In this case, the string was missing
its terminator. This confused the API function GetLocaleInfoW(),
causing it to think that '0' (ASCII number zero) was the positive sign
for the current locale (it should normally be '+'). This caused all
kinds of havoc.
You can verify this for yourself with regedit.exe: open that reg value
by right-clicking on the value and selecting 'Modify Binary Data'.
You should see two dots on the right (representing the null
terminator). If you see no dots, you're affected. Fix it by adding a
terminator (four zeros).
You can also check the value of
CultureInfo.CurrentCulture.NumberFormat.PositiveSign; it should be
'+'.
It's a bug in the Windows localization API, not the class libs. The
reg value needs to be checked for a terminator. They're looking at it.
Michael