SetLocale and automatic conversion

Discussion:

(too old to reply)

R.Wieser

2015-07-11 12:58:04 UTC

Hello All,

I'm reading values outof a file, and ran into troubles because the
decimal-point notation was different of that of my local settings (Europe
uses "," where the USA uses ".").

After some google-digging I found the SetLocal() command, and it works
well-ish.

The problem is that it only seems to affect other commands (like CDbl() ),
but *not* any automatic conversion (which is a "disaster" waiting to
happen). :-|

Example:
"3.4" + 1 => 35 (the dot is simply "forgotten")
CDbl("3.4") + 1 => 4,4

Question:
How do get the automatic conversions to honour the localisation-setting too
?

Further info:
I've embedded a scripting-object into a program of mine, so I've got quite a
bit of access to all its objects. I've already been playing with the
GetLCID command (returning different LCIDs), but can't seem to evoke any
changed response.

Regards,
Rudy Wieser

Mayayana

2015-07-11 13:50:34 UTC

Permalink

I'm guessing the string is
the problem. VBS allows us to be lazy, ignoring
data types. It will coerce a value into whatever
variant sub-datatype seems best.

Example: "3.4" + 1 shouldn't work because
it tries to add a string to a numeric value. But
it does work because VBS provides kindergarten-
level protection from such details. VBS even lets
us ignore operators. (& for string and + for numeric.)
And it lets us ignore proper spacing. It will basically
fix our code behind the scenes, assuming that
we're barely capable of writing the code at all.

In this case it's being so accomodating that it
will even convert non-numeric values. CDbl("3.4")
apparently should error for you, just as CDbl("tree")
will error. Instead VBS is doing its best to make the
conversion work by dropping the period, because
you've explicity insisted that you want a number.
That appears to be an internal bug. VBS will drop
out a comma for me, but I can't find any other
character that it treats the same way. If it drops
a comma it should also drop "t", or "-", or anything
else that's not an operator, but it doesn't.

Given that, I would think the solution is to make
sure you give it something coherent. If you're using
European style and want to make a numeric conversion
from a string then run a Replace on it first to make
sure that string is a valid numeric. Then do an explicit
conversion. I get True for IsNumeric("3,4"), so it looks
like it's at least being consistent. You can reliably test
whether a Replace is going to work on a given string.

I got to playing around with this and tried:
MsgBox 3,4 + 1 (US)
I got a message box with a caption of "3" and
Retry/Cancel buttons. :)

R.Wieser

2015-07-11 15:22:13 UTC

Permalink

Mayayana,

Post by Mayayana
It will coerce a value into whatever
variant sub-datatype seems best.

Yep. That is, AFAICT, exactly the point of the problem. Although the
silent coercion is very handy for a scripting-language like VBScript, it
does have its downsides. Like not doing the same as the explicit coercions.

Ofcourse, the scripting engine doesn't, and I have the need to figure out,
if at all possible, how to get a consistent behaviour in a script. One that
does give the same results regardless of explicite or implicite conversions.

What I also did not expect was the laissez faire attitude towards the
acceptance of a numeric formatting.

As far as I can tell its not at all customary, in the US, to write"three
thousand four hundred dollar" as 4,3 dollar. When that thousands
seperator is used right of it should always be three digits: 4,300 dollar
(correct me if I'm wrong please) . In other words: the thousands seperator
should only appear every third place from the right/the place of the decimal
dot. Or not at all. Any other combination should result in an conversion
error.

Actually, if the above is applied to an an automatic detection of American
versus European numeric formatting should be possible (hmmm ....).

Post by Mayayana
Given that, I would think the solution is to make
sure you give it something coherent.

The textfile I read the values from is quite coherent: all the values have
the same formatting, which conforms to the US standard. So thats not the
problem.

Post by Mayayana
I get True for IsNumeric("3,4"), so it looks
like it's at least being consistent

That unusable result of the above command jolted me to test some more
combinations. I think we can agree that you and I would directly recognise
the below "value" as faulty:

(US settings)
wscript.echo IsNumeric("3,,2,1.5,6")
wscript.echo "3,,2,1.5,6"+1
wscript.echo CDbl("3,,2,1.5,6")

Alas, VBScript doesn't. :-(

Post by Mayayana
MsgBox 3,4 + 1 (US)
I got a message box with a caption of "3" and
Retry/Cancel buttons. :)

:-)

Regards,
Rudy Wieser

Post by Mayayana
I'm guessing the string is
the problem. VBS allows us to be lazy, ignoring
data types. It will coerce a value into whatever
variant sub-datatype seems best.
Example: "3.4" + 1 shouldn't work because
it tries to add a string to a numeric value. But
it does work because VBS provides kindergarten-
level protection from such details. VBS even lets
us ignore operators. (& for string and + for numeric.)
And it lets us ignore proper spacing. It will basically
fix our code behind the scenes, assuming that
we're barely capable of writing the code at all.
In this case it's being so accomodating that it
will even convert non-numeric values. CDbl("3.4")
apparently should error for you, just as CDbl("tree")
will error. Instead VBS is doing its best to make the
conversion work by dropping the period, because
you've explicity insisted that you want a number.
That appears to be an internal bug. VBS will drop
out a comma for me, but I can't find any other
character that it treats the same way. If it drops
a comma it should also drop "t", or "-", or anything
else that's not an operator, but it doesn't.
Given that, I would think the solution is to make
sure you give it something coherent. If you're using
European style and want to make a numeric conversion
from a string then run a Replace on it first to make
sure that string is a valid numeric. Then do an explicit
conversion. I get True for IsNumeric("3,4"), so it looks
like it's at least being consistent. You can reliably test
whether a Replace is going to work on a given string.
MsgBox 3,4 + 1 (US)
I got a message box with a caption of "3" and
Retry/Cancel buttons. :)

Mayayana

2015-07-11 15:45:21 UTC

Permalink

| As far as I can tell its not at all customary, in the US, to write"three
| thousand four hundred dollar" as 4,3 dollar. When that thousands
| seperator is used right of it should always be three digits: 4,300 dollar
| (correct me if I'm wrong please) . In other words: the thousands
seperator
| should only appear every third place from the right/the place of the
decimal
| dot. Or not at all. Any other combination should result in an conversion
| error.
|

I assume you meant 3,400. No, I've never seen
anyone write anything like 3,4 for 3,400. It's not
feasible as far as I can tell. There's no way to
deduce the number of zeros that follow. But VBS
doesn't seem to be doing that. From my tests it
seems to only have a bug where , and . are
concerned. Like your tests, my tests with 3,4
show WSH dropping the comma rather than
interpreting it.

R.Wieser

2015-07-11 17:03:17 UTC

Permalink

This post might be inappropriate. Click to display it.

Ruediger Roesler

2015-07-11 15:17:50 UTC

Permalink

Post by R.Wieser
I'm reading values outof a file, and ran into troubles because the
decimal-point notation was different of that of my local settings
(Europe uses "," where the USA uses ".").
After some google-digging I found the SetLocal() command, and it works
well-ish.
The problem is that it only seems to affect other commands (like
CDbl() ), but *not* any automatic conversion (which is a "disaster"
waiting to happen). :-|
"3.4" + 1 => 35 (the dot is simply "forgotten")
CDbl("3.4") + 1 => 4,4
How do get the automatic conversions to honour the
localisation-setting too ?
I've embedded a scripting-object into a program of mine, so I've got
quite a bit of access to all its objects. I've already been playing
with the GetLCID command (returning different LCIDs), but can't seem
to evoke any changed response.

The GetLocale and SetLocale functions refers only to In- and Output.
This little code example should explain that closer:

'############################ Add1.vbs ################################
For Each str In WSH.Arguments
WSH.Echo
For Each i In Array("de-de", "en-us", "en-gb", "nl-nl", "fr-fr")
SetLocale(i)
If IsNumeric(str) Then
WSH.Echo i & ": " & CDbl(str) & " + 1 = " & CDbl(str) + 1
Else
WSH.Echo "Is not a numeric value in " & i & ": " & str
End If
Next
Next
'############################ Add1.vbs ################################

If you run it on the command line, the result is:

C:\>Add1 3,4 3.4

de-de: 3,4 + 1 = 4,4
en-us: 34 + 1 = 35
en-gb: 34 + 1 = 35
nl-nl: 3,4 + 1 = 4,4
fr-fr: 3,4 + 1 = 4,4

de-de: 34 + 1 = 35
en-us: 3.4 + 1 = 4.4
en-gb: 3.4 + 1 = 4.4
nl-nl: 34 + 1 = 35
Is not a numeric value in fr-fr: 3.4

For writing code in VBScript you have to use the syntax of VBScript. :-)
And a variable of the type double is always written with a decimal
point.

--
ЯR

R.Wieser

2015-07-11 15:28:00 UTC

Permalink

Ruediger,

Post by Ruediger Roesler
And a variable of the type double is always written
with a decimal point.

I'm not at all sure if I understand you here, as the output of your own code
already shows otherwise ...

Regards,
Rudy Wieser

-- Origional message

Post by Ruediger Roesler

The GetLocale and SetLocale functions refers only to In- and Output.
'############################ Add1.vbs ################################
For Each str In WSH.Arguments
WSH.Echo
For Each i In Array("de-de", "en-us", "en-gb", "nl-nl", "fr-fr")
SetLocale(i)
If IsNumeric(str) Then
WSH.Echo i & ": " & CDbl(str) & " + 1 = " & CDbl(str) + 1
Else
WSH.Echo "Is not a numeric value in " & i & ": " & str
End If
Next
Next
'############################ Add1.vbs ################################
C:\>Add1 3,4 3.4
de-de: 3,4 + 1 = 4,4
en-us: 34 + 1 = 35
en-gb: 34 + 1 = 35
nl-nl: 3,4 + 1 = 4,4
fr-fr: 3,4 + 1 = 4,4
de-de: 34 + 1 = 35
en-us: 3.4 + 1 = 4.4
en-gb: 3.4 + 1 = 4.4
nl-nl: 34 + 1 = 35
Is not a numeric value in fr-fr: 3.4
For writing code in VBScript you have to use the syntax of VBScript. :-)
And a variable of the type double is always written with a decimal
point.
--
?R

Ruediger Roesler

2015-07-11 17:11:44 UTC

Permalink

Post by R.Wieser

Post by Ruediger Roesler
And a variable of the type double is always written
with a decimal point.

I'm not at all sure if I understand you here, as the output of your
own code already shows otherwise ...

Sorry, it did not.

Ok, it's a little bit confusing, I have expanded the code a little bit:

'############################ Add1.vbs ################################
For Each str In WSH.Arguments
For Each i In Array("de-de", "en-us", "en-gb", "nl-nl", "fr-fr")
SetLocale (i)
WSH.Echo vbCRLF & "Calculate the value of " & str & " plus 1:"
If IsNumeric(str) Then
WSH.Echo i & ": " & CDbl(str) & " + 1 = " & CDbl(str) + 1
WSH.Echo i & ": " & str & " + 1 = " & str + 1
Else
WSH.Echo "Is not a numeric value in " & i & ": " & str
End If
WSH.Echo vbCRLF & "Now computing another value for output:"
WSH.Echo i & ": " & 3.141 & " * 10^3 + 1 = " & 3.141 * 10^3 + 1
WSH.Echo i & ": " & 3,141 & " * 10^3 + 1 = " & 3,141 * 10^3 + 1
Next
Next
'############################ Add1.vbs ################################

You see the different results in French? In the French locale conversion
the correct number of digits is checked, otherwise it results in an
error. In other language conversions it's not. SetLocale refers only to
the output of strings, but also to the conversion of input strings into
the correct VBScript format for a calculation of digits.

The locale conversion routine parses the digits for separation signs and
removes them all, but not in the french version, there they will be only
removed if the number of digits is right (three!). The behaviour of
VBScript seems a little bit astonishing, I have to confess. Maybe I have
understand you wrong because I have not seen your code and what do you
want.

--
ЯR

R.Wieser

2015-07-11 18:17:30 UTC

Permalink

Ruediger,
I'm sorry, but I still don't.

For both of the types of values some of the converted CDbl() results do not
show any "decimal point" (either a dot or a comma). See the first group,
'en-??' and for the second group 'de' and 'nl'.

Post by Ruediger Roesler
You see the different results in French?

Yep, I did see that. It looks like their value gets checked better than for
the others. Oh well, the frenchies always thought of themselves as
"better" than the rest of the world. :-)

Post by Ruediger Roesler
Maybe I have understand you wrong because I have not
seen your code and what do you want.

My origional problem is not (specific) code related. Its the way VBScript
seems to handle implicite coercion different than explicite coercion
("3.4"+1 versus CDbl("3.4")+1).

To be honest though, I just tried to re-reproduce the effect (which I
thought I already saw earlier), and simply can't ... <huh> :-(

A *later* discovery/problem was that VBScript is quite cavalier with where
it accepts thousands-seperator symbols (like in *everywhere*).

Regards,
Rudy Wieser

Post by Ruediger Roesler

Post by R.Wieser

Post by Ruediger Roesler
And a variable of the type double is always written
with a decimal point.

I'm not at all sure if I understand you here, as the output of your
own code already shows otherwise ...

Sorry, it did not.
'############################ Add1.vbs ################################
For Each str In WSH.Arguments
For Each i In Array("de-de", "en-us", "en-gb", "nl-nl", "fr-fr")
SetLocale (i)
WSH.Echo vbCRLF & "Calculate the value of " & str & " plus 1:"
If IsNumeric(str) Then
WSH.Echo i & ": " & CDbl(str) & " + 1 = " & CDbl(str) + 1
WSH.Echo i & ": " & str & " + 1 = " & str + 1
Else
WSH.Echo "Is not a numeric value in " & i & ": " & str
End If
WSH.Echo vbCRLF & "Now computing another value for output:"
WSH.Echo i & ": " & 3.141 & " * 10^3 + 1 = " & 3.141 * 10^3 + 1
WSH.Echo i & ": " & 3,141 & " * 10^3 + 1 = " & 3,141 * 10^3 + 1
Next
Next
'############################ Add1.vbs ################################
You see the different results in French? In the French locale conversion
the correct number of digits is checked, otherwise it results in an
error. In other language conversions it's not. SetLocale refers only to
the output of strings, but also to the conversion of input strings into
the correct VBScript format for a calculation of digits.
The locale conversion routine parses the digits for separation signs and
removes them all, but not in the french version, there they will be only
removed if the number of digits is right (three!). The behaviour of
VBScript seems a little bit astonishing, I have to confess. Maybe I have
understand you wrong because I have not seen your code and what do you
want.
--
?R

Ruediger Roesler

2015-07-11 19:26:39 UTC

Permalink

Post by R.Wieser
For both of the types of values some of the converted CDbl() results
do not show any "decimal point" (either a dot or a comma). See the
first group, 'en-??' and for the second group 'de' and 'nl'.

Post by Ruediger Roesler
You see the different results in French?

Yep, I did see that. It looks like their value gets checked better
than for the others. Oh well, the frenchies always thought of
themselves as "better" than the rest of the world. :-)

Post by Ruediger Roesler
Maybe I have understand you wrong because I have not
seen your code and what do you want.

My origional problem is not (specific) code related. Its the way
VBScript seems to handle implicite coercion different than explicite
coercion ("3.4"+1 versus CDbl("3.4")+1).
To be honest though, I just tried to re-reproduce the effect (which I
thought I already saw earlier), and simply can't ... <huh> :-(
A *later* discovery/problem was that VBScript is quite cavalier with
where it accepts thousands-seperator symbols (like in *everywhere*).

And that is the reason why Bill Gates became the richest man of the
world. His account was originally at an amount of 60 US-$$, and he
hacked into and added a single 10^9 to it. And his bank did not
recognized it. That is the whole true story! And if he has not died, he
will live and prosper, because that is the problem, you cannot reproduce
it and that's the reason why there is no proof. lol

"They have blamed theirself," he said.

--
ЯR

R.Wieser

2015-07-11 20:02:40 UTC

Permalink

Ruediger,

you cannot reproduce it and that's the reason why there is no proof. lol

I cannnot prove the first problem (still don't know why I can't find it
back), but its easy to prove the second :

SetLocale(&h0409)
wscript.echo CDbl("6,,,,,5,,,4.3,,2,,,,,1")

Good enough for you ?

Regards,
Rudy Wieser

Post by Ruediger Roesler
You see the different results in French?

Yep, I did see that. It looks like their value gets checked better
than for the others. Oh well, the frenchies always thought of
themselves as "better" than the rest of the world. :-)

Post by Ruediger Roesler
Maybe I have understand you wrong because I have not
seen your code and what do you want.

My origional problem is not (specific) code related. Its the way
VBScript seems to handle implicite coercion different than explicite
coercion ("3.4"+1 versus CDbl("3.4")+1).
To be honest though, I just tried to re-reproduce the effect (which I
thought I already saw earlier), and simply can't ... <huh> :-(
A *later* discovery/problem was that VBScript is quite cavalier with
where it accepts thousands-seperator symbols (like in *everywhere*).

R.Wieser

2015-07-12 09:56:32 UTC

Permalink

Ruediger,

because that is the problem, you cannot reproduce it

Although that was true at the moment I wrote it, thats no longer the case.
Some mental retracing of what the circumstances where at the moment I
noticed the problem was needed though (I'm not in the habit of posting a
problem and than sit back until someone presents me the solution, so I had
done several things-and-tests in the mean time).

The problem consists outof a VariantChangeType function (which I used in an
object I wrote in the same thread that creates the scripting object, so it
could handle any type of supplied variant content) which doesn't seem to
listen to the localisation applied in/to the script.

A further test revealed that the thread the above function was called in
(the same one the engine was created in) still had the default LCID, instead
of the one set in.by the script (also indicating that the scripting engine
runs in a different thread). Hence the differences.

In short, the problem is not caused by the scripting engine itself.

Though to my defense I have to mention that my google-digging in regard to
localisation changing in VBScript did turn up an article where an
inconsistent behaviour between implicite and explicite conversion was
described, which I (too fast and wrongly) assumed was the base of my current
problem. Mea culpa.

Now all I need to do is to figure out how to (catch-and-)copy the
script-engines localisation setting to the current thread, without having to
do that before every usage of that above mentioned VariantChangeType
function.

Regards,
Rudy Wieser

Post by Ruediger Roesler
You see the different results in French?

Yep, I did see that. It looks like their value gets checked better
than for the others. Oh well, the frenchies always thought of
themselves as "better" than the rest of the world. :-)

Post by Ruediger Roesler
Maybe I have understand you wrong because I have not
seen your code and what do you want.

My origional problem is not (specific) code related. Its the way
VBScript seems to handle implicite coercion different than explicite
coercion ("3.4"+1 versus CDbl("3.4")+1).
To be honest though, I just tried to re-reproduce the effect (which I
thought I already saw earlier), and simply can't ... <huh> :-(
A *later* discovery/problem was that VBScript is quite cavalier with
where it accepts thousands-seperator symbols (like in *everywhere*).

Todd Vargo

2015-07-11 18:26:55 UTC

Permalink

Post by Ruediger Roesler

C:\>Add1 3,400 3.400

de-de: 3,4 + 1 = 4,4
en-us: 3400 + 1 = 3401
en-gb: 3400 + 1 = 3401
nl-nl: 3,4 + 1 = 4,4
fr-fr: 3,4 + 1 = 4,4

de-de: 3400 + 1 = 3401
en-us: 3.4 + 1 = 4.4
en-gb: 3.4 + 1 = 4.4
nl-nl: 3400 + 1 = 3401
Is not a numeric value in fr-fr: 3.400

So this basically proves Garbage in Garbage out.

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

R.Wieser

2015-07-11 19:48:23 UTC

Permalink

Todd,

Post by Todd Vargo
C:\>Add1 3,400 3.400

...

Post by Todd Vargo
So this basically proves Garbage in Garbage out.

Yep. But at the same time: Nope.

The problem is that the "Garbage out" should never have happened (some bad
input validation there), and an error should have been thrown instead.
*Especially* when doing an explicit conversion.

Regards,
Rudy Wieser

Post by Todd Vargo

Post by Ruediger Roesler

C:\>Add1 3,400 3.400
de-de: 3,4 + 1 = 4,4
en-us: 3400 + 1 = 3401
en-gb: 3400 + 1 = 3401
nl-nl: 3,4 + 1 = 4,4
fr-fr: 3,4 + 1 = 4,4
de-de: 3400 + 1 = 3401
en-us: 3.4 + 1 = 4.4
en-gb: 3.4 + 1 = 4.4
nl-nl: 3400 + 1 = 3401
Is not a numeric value in fr-fr: 3.400
So this basically proves Garbage in Garbage out.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)