BUG: Microsoft.VisualBasic.Conversion.Val(string)

  • Thread starter Thread starter Daniel Moth
  • Start date Start date
D

Daniel Moth

Hi

This is reproducible on our own 4.2 based device as well as in the
emulator.. with SP1 or the current SP2 beta... Haven't tried on a PocketPC
maybe someone else can please(?)

When the locale is set to something like French (where decimal separators
are commas and not dots) calling Val("23.45") throws a
System.FormatException... Note that the same function call on the desktop
works as expected and as documented (i.e. The Val function recognizes only
the period (.) as a valid decimal separator)

Interestingly passing "23,45" to it returns 23,00... which is correct (Val
stops converting at the first character that cannot be interpreted as a
numeric digit, numeric modifier, numeric punctuation, or white space.)

I had a quick look with Anakrino on the desktop and cf implementations of
Microsoft.VisualBasic.Conversion.Val(string) and they seem identical except
they both call HexOrOctValue which have slight differences... Any ideas?

In the meantime since C# does not have an equivalent maybe someone has
written a handy function I could use until it gets fixed...(?)

Cheers
Daniel

PS In case the repro line of code was not clear just execute the
following when the locale is set to French...

MessageBox.Show(Microsoft.VisualBasic.Conversion.Val("34.3").ToString())
 
For info the converse Str function seem to work as expected... I.e.
Str(aDoubleVariable) returns X.Y and never a comma or an exception
regardless of regional settings...

Cheers
Daniel
 
Daniel,

I use Convert.ToDouble (or whatever is the appropriate numeric data type) in
C# to convert strings to numbers. I also put this type of code inside a
try...catch block since the data I'm parsing might be incorrectly formatted.
 
Hi thanks

Unfortunately, Convert.ToDouble does not do what Val does (Convert.ToDouble
is more like CDbl)...

Val (among other things) parses a string value in the X.Y format even when
the Globalization.NumberFormatInfo.CurrentInfo.NumberDecimalSeparator is a
comma (,)

I have VB code (upgraded from VB6) that uses Val and Str quite a lot - and
it has to, we don't want in those algorithms locale aware
parsing/building... (as the string values arrive from a network where the
decimal separator is always a dot)

Given that the same code works as expected on the desktop, I think this is a
bug and should be at least recognised by MS as such... Still looking for a
workaround though so thanks for the thought... My guess is there isn't an
equivalent in C# or the framework classes and I am going to have craft my
own...

Cheers
Daniel
 
Daniel,

You may be right that it's a bug. I'm not a VB programmer so I defer to your
experience as to what the expected behavior would be.

On the desktop, you can change the Thread.CurrentThread.CurrentCulture on
the fly. Since we don't have that option in the compact framework, would it
work for you to first convert any commas to decimals, then use
Convert.ToDouble?
 
Hi

On the bug front, my experience has nothing to do with it :-) The same line
of code works great on the desktop (as documented in your MSDN
documentation) and bombs on the CF.

Replacing commas with dots is only part of the story but you are right it is
part of the solution (which I am coding up)...

Val can take strings like
"1234abc5" and return 1234 or
"bug12" and return 0 or
" 12.3abc" and return 34,5 etc...

Its one of those functions that you don't have to use often but when you do
you really do if you know what I mean...

Cheers
Daniel
 
Daniel,

The behavior you describe is similar to Val in xBase langauges, so I am
familiar with it except for the commas in other cultures. I think you should
be able to write your own Val work-alike now that you have described it so
well. After replacing commas with decimals if necessary, put a try...catch
block around the Convert.ToDouble, and in the catch statement you could
return 0. Anyway, you get the gist of it.
 
Ginny,

Thanks I get the gist of it... Actually the function has to walk the whole
string char by char but that's irrelevant... Sorry I mistyped my 3rd
example, it should have been:
" 12.3abc" and return 12,3 etc...

Can someone from MS acknowledge this as a bug please OR anybody tell me what
I am missing?

Cheers
Daniel
 
Back
Top