I found this one by accident.

I was illustrating TextBox Extender component that I had developed that automatically validates any TextBox on a form. I enterd "123" the TextBox and all was right with the world. I added ".-" in an attempt to make it non-numeric, when I got an application exception. Investigation revealed the following:

IsNumeric("123.-") ' Returns True

IsNumeric("123.+") ' Returns True

IsNumeric("123.*") ' Returns False

IsNumeric("123./") ' Returns False

Double.Parse("[Any of the above Combinations]") ' Returns System.FormatException

Is this a bug in the Framework? Or is there something I'm missing?


UPDATE:

CDbl("123.-") ' Returns -123.0

CType("123.-", Double) ' Returns -123.0

This is really interesting. The default implementation of Double.Parse() is not the same as simply casting the string to a double.

Comments

# re: I found this one by accident.

Wednesday, August 24, 2005 9:56 AM by Damien Guard

123.- is valid because some number formats place the sign after the number.

Same goes for +, they are both valid because they are signs.

/ and * are false because they are only mathematical operators.

[)amien

# re: I found this one by accident.

Wednesday, August 24, 2005 10:07 AM by Chris McKenzie

I can understand that--but if the number format is valid then shouldn't double.parse() parse it correctly? Or if it's a matter of having to supply the number format, shouldn't the default format used by IsNumeric() correspond to the default format used by double.parse()?

# re: I found this one by accident.

Wednesday, August 24, 2005 11:26 AM by Alan Yeung

I rather use RegEx for validation.

# re: I found this one by accident.

Wednesday, August 24, 2005 11:56 AM by Matt B

"but if the number format is valid then shouldn't double.parse() parse it correctly?"

I would guess that Isnumeric and Double.Parse both use the default format if one is not specified, and that this format isn't correct for the default culture/format of the app.

Double.TryParse should be really be used.

# re: I found this one by accident.

Wednesday, August 24, 2005 12:56 PM by Chris McKenzie

They should, but per the above example, they apparently do not.

# re: I found this one by accident.

Wednesday, August 24, 2005 1:00 PM by None

Isn't IsNumeric a VB.Net function in the Microsoft.VisualBasic namespace. I'm guessing the the way IsNumeric checks for validity is different from Double.Parse. Maybe, the people who wrote VB.net at MS decided they would have IsNumeric work the same way as in previous version of VB and not have it work the same way as Double.Parse.

# re: I found this one by accident.

Wednesday, August 24, 2005 1:09 PM by Chris McKenzie

It is a legacy function from VBx, yes. I'm guessing that the issue probably never came up at MS. The casting functions (CDbl(), CInt(), CBool()) also existed in VBx. A quick check reveals that CDbl("123.-") yields -123.0. So what have we learned? That CDbl() is not a wrapped call to Double.Parse(). Intersting.

# re: I found this one by accident.

Wednesday, August 24, 2005 4:22 PM by Jesse Arnold

Microsoft.VisualBasic != mscorlib

The legacy VB functions are not just wrappers around the .NET framework, since they retain the legacy behavior.

Lesson learned: Avoid Microsoft.VisualBasic namespace if you want predictable and consistant behaviour as other .net languages.

Check this out with Reflector:
Microsoft.VisualBasic.Conversion.Val(String) : Double

# Directories Blog » Blog Archive » Coombe Abbey Bedrooms Overview

Pingback from  Directories Blog  » Blog Archive   » Coombe Abbey Bedrooms Overview

# Feed Search Engine - All Fresh Articles And News Are Here

Sunday, November 25, 2007 6:41 PM by Feed Search Engine - All Fresh Articles And News Are Here

Pingback from  Feed Search Engine - All Fresh Articles And News Are Here

Leave a Comment

(required) 
(required) 
(optional)
(required)