back in the day, I seem to recall that if you used VAL() on a number that was user-entered, you could get the wrong values when decimals were involved.
eg on a UK/USA system, Val(“3.1”) = 3.1
whereas if the locale was EU, Val(“3.1”) = 3
or similarly
on a UK/USA system, Val(“3,1”) = 3
whereas if the locale was EU, Val(“3,1”) = 3.1
CDbl is supposed to handle localisation.
But today I have been debugging an issue, and found that if user-entered 3.1
and the system is in EU locale,
CDbl(“3.1”) produces 31, not 3
This seems new (and buggier than losing the matissa) ?
I’m not sure whether this is really new … Given the locale, “3.1” is not a well-formed number; “.” is the thousands separator but the number, whatever it is, is smaller than 1000 so there shouldn’t be a “.” anywhere. Apparently Cdbl simply ignores the thousands separator (as it is only used for presentation purposes anyway) and accepts numbers where it is used incorrectly, like “3.1000” which is read as 31000.
Now the question is: What should Cdbl do in these cases?
To be fair, I’m not suggesting Cdbl has a bug.
3.1 in an EU environment is a ‘bad number’ and is user error.
Its this jump from ‘take the value up until the first bad character’ which would have given 3 (pretty close but not 100% accurate) to 31 (nowhere near the correct value) , which threw me.
Inherited from the BASIC standard, since always, CDbl() (and all CWhateverConversion where applicable) is locale sensitive, Val() is not, Val assumes period as decimal separator always and stops conversion as soon as any invalid char is found.
That said, let’s compare some VB.Net vs Xojo differences I’ve found.
VB.Net is more rigid, Xojo seems more relaxed and fails silently.
In both languages Val() is relaxed and CWhatever is more rigid raising exceptions in VB.Net.
VB.Net:
Val("3.1") // should always end as 3.1 (always use period as decimal separator)
Val("3,1") // should always end as 3. Stop conversion at non valid char.
Val(" 3 1 2 ") // should end as 312, because spaces are ignored.
CDbl("3.1") // in the US ends as 3.1
CDbl("3.1") // in many countries raises an exception due to a invalid char (comma expected).
CDbl("3 1") // raises a conversion fail exception, invalid char found.
Xojo:
CDbl("3.1") // in the US ends as 3.1
CDbl("3.1") // in many countries using a comma seems just ignored and ends as 31
CDbl("3 1") // ends as 3, stop conversion at the invalid char " "
Val("3.1") // should always end as 3.1 (always use period as decimal separator)
Val("3,1") // should always end as 3. Stop conversion at non valid char ",".
Val(" 3 1 2 ") // Ends as 3, stop conversion at the space after the first digit.
But then again, what is the correct value? We don’t really know. The safest option would be to throw an exception whenever there is a misplaced thousands separator, or indeed any deviation from a well-formed number (relative to the locale).
The current implementation of Cdbl tries to be as robust and generous as possible and to make sense of most anything thrown at it, which may not be the best way to deal with sloppy user input.
Well of course. Cdbl interprets a number according to the locale so “.” may be the decimal point, the thousands separator or whatever. In this case it is taken to be the thousands separator and eventually just ignored.
None of us mere customers can offer any real help as we cannot change the implementation. And if we argue for a change in the implementation it should be a change that most of us agree is an improvement.
I would opt for raising an exception as any specific interpretation of a malformed number would be correct in some cases and incorrect in others.
I do now have a workaround, of course.
It may not have changed. But then, the specific bug report I received about my software is the first instance in a product that has had a 20 year lifespan in one form or another.
For me, the issue arose inside a 3rd party component from an ex-forum member.
Luckily I had the source code and could address it myself.
Fair question.
I’m still trying to avoid API2 as much as possible.
(It’s a losing battle.. the IDE keeps slipping in the new syntax, and I’ve lost track of what is API1 and API2.
Like religion and politics, best to avoid the topic. )
0 times a day. It seemed quite obvious to me. It is more consistent. Others will not doubt complain and say the opposite. That’s for them to judge for themselves. We’re fine with API2 and that’s fine too.
60 and I’ve known more languages than I care to remember over the years. Really, since retirement working just with Xojo life is a lot easier than all the ones I used to have to deal with over the last 35-40 years.