Some of you might have noticed that there’s less “low-down-dirty” coding related posts on this blog of late. It’s probably because my job role has become more business-driven, change-agenty, people-focused as of late. However, I’ll take a break from the posts on Management Strategy, Debt Negotiation, Risk and Segmentation and drop a coding titbit that I might end up searching for in the future.
Turns out that we came across an obscure bug today in VB.Net. One of our testers tried using 1- as an input value in a numeric field and this ended up blowing up an application. Faulty validation you may argue, but no, the field had been validated using the IsNumeric function, which reported it as being numeric. However, if you then try to convert is using: Convert.ToInt32, you get an error that says: input string was not in a correct format
. However, if you CType the value into an integer or use CInt, the value is correctly parsed. This is also the case with brackets. For example “(1)” returns true as isnumeric, throws an exception as Convert.ToInt32 and returns “-1” with CType and CInt.
It’s funny how theseidiosyncrasies can creep into a language and end up rearing their head when you least expect them. Wonder if this is fixed in a later version of .Net
Interesting little glitch. I never used VB.Net But I did do VB6 a bit.
Hey Owen, what version of VB.NET was that?
We tested it in both v1.1 and v2.0, so currently all versions of .Net (as I presume it would affect 3.0 also)
I was wondering which version of VB.NET the software was coded in rather than the .NET framework version?