Re: Very strange "input string not in correct format" bug
- From: "Jen" <none@xxxxxxxxxxx>
- Date: Wed, 7 Mar 2007 15:01:57 -0500
It is very strange, that's for sure. Like in the example trace I posted
notice it was the 3rd octet of the IP address that threw the exception.
There were two octets before that that worked fine! Of course the numbers
in the textboxes are all different but all of them had valid small integers.
"Laura T." <LT@xxxxxxxxxxx> wrote in message
news:ekmChRMYHHA.4560@xxxxxxxxxxxxxxxxxxxxxxx
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" <none@xxxxxxxxxxx> ha scritto nel messaggio
news:ucjHptLYHHA.4560@xxxxxxxxxxxxxxxxxxxxxxx
I can't really do a detailed analysis of the differences because the
offending machine is not accessible to me at the moment.
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." <LT@xxxxxxxxxxx> wrote in message
news:eKdCTELYHHA.596@xxxxxxxxxxxxxxxxxxxxxxx
What diffrences have the machines that generate exception?
Framework version, hot fixes, OS fixes, UI language/culture etc.?
I tried to reproduce the exception by setting the thread culture to all
possibile cultures I have (158) but did not get any exception from
Convert.ToInt16("172").
The only thing I cannot test that could have something to do with
cultures
are the UI cultures but, I'd rather check first what are the
differences.
"Jen" <none@xxxxxxxxxxx> ha scritto nel messaggio
news:%233ZUVgCYHHA.4520@xxxxxxxxxxxxxxxxxxxxxxx
One user of my application is experiencing an exception "input string
not
in correct format". But it makes no sense where it is occurring. It
is
occurring when a string from a textbox ("172") is being convert to an
Int16 (using Convert.ToInt16). How can that be? There are other text
boxes that are used in the identical fashion and they don't generate
the
exception. All there are many other machines running my application
that
don't generate the exception at all.
I have no idea what the problem could be and am looking for ideas.
.
- References:
- Prev by Date: About using XMLValidatingReader
- Next by Date: Re: Using String.Empty as a SyncLock object
- Previous by thread: Re: Very strange "input string not in correct format" bug
- Next by thread: Re: Very strange "input string not in correct format" bug
- Index(es):
Relevant Pages
|
Loading
