Vista - boolean localization problem

Hi,

I have found that on different languages the boolean value may differ (not
the value itself - but its string representation...)

For example the "IPEnabled" boolean value (see
http://msdn.microsoft.com/en-us/libr...17(VS.85).aspx ) :

On an english Windows installation the boolean value for "IPenabled" will
be given as a string : "true" / "false"
On a french Windows it will be "vrai" / "faux" ... and on a German Windows
"wahr" / "falsch" .... etc.

Is there a way to get a boolean value language independent (from the WMI
classes), so for example -1 / 0 instead of language dependent strings ?

Thank you

Heinz schrieb:A boolean value is either True or False. The language specific
text representations are created when you cast/convert the boolean
value to a string
Wahr

if you cast it - implicitly or explicitly - to a number, you'll get
0 resp. -1
-1 0 -1 0

As the strings are correct for informing a user and you don't need
conversions to use booleans in expression, I wonder why this is
a problem for you (just interested).

Heinz,
It really is a boolean. What you're seeing is an artifact of using MsgBox
for output display. MsgBox coerces certain data types to localized strings.

If you're worried about localization issues, I would avoid using MsgBox
unless really needed for actual _choices_ to be made. Instead, use
WScript.Echo.

If you do need to use MsgBox - or InputBox, it has the same issues - for
getting feedback from a user, coerce the value to an integer before
displaying it. The value will then be rendered as a number.

Demo code:

dim x: x = True
' The following shows the type name, vartype, and normal representation of
x:
' Boolean 11 -1
WScript.Echo "from WScript.Echo:", TypeName(x), VarType(x), x
' The following shows the localized string value for x:
MsgBox x
' which is equivalent to this:
WScript.Echo CStr(x)
' Since MsgBox is mangling it, no boolean coercion will help, no matter how
ridiculous:
MsgBox CBool(CBool(CBool(CBool(x))))
' This, however, does work: just turn it into an integer
MsgBox CInt(x)
' Note the same issues happen with InputBox:
InputBox "This is x as converted by InputBox automatically: " & x
InputBox "This is x pre-coerced to integer: " & CInt(x)


"Heinz" <no@xxxxxx> wrote in message
news:eyE5izO5JHA.1432@xxxxxx

Alex K. Angelopoulos schrieb:I would avoid words like "artifact", "coerce", or "mangling". All
display functions dutifully convert the data to be shown to a (localized)
text representation (probably by using CStr() internally).
WScript.Echo behaves exactly like MsgBox; so why the "instead"? When
communicating with a user, using "True", "Wahr", or "vrai", ... seems
appropriate to me. That's why I don't like the next proposal at all.
[...]

"ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
news:4a27a45b$0$32663$9b4e6d93@xxxxxx-online.net...OK, artifact is a _bad_ word here; but not coerce. MsgBox really is coercing
the value to a string from what I can tell.
Exactly?
x=true
WScript.Echo x

The reason I recommended the coercion wasn't because it's "always better",
but because Heinz wanted output that was in the form of -1/0 - and that gets
it for him.

"ekkehard.horner" <ekkehard.horner@xxxxxx> schrieb im Newsbeitrag
news:4a279578$0$32676$9b4e6d93@xxxxxx-online.net...Hi,

the problem is (or was) that I write the result of a boolean variable like
"IPEnabled" to a textfile - so in the textfile I get either
true","false" - "wahr","falsch" - "vrai","faux" etc.
The problem starts when I read this textfile into an application and try to
determine whether this boolean was true or false...

But CInt(boolean) does the trick - instead of a text it writes "-1" or
"0" to the textfile (ok... this is a string, too.... but it is not language
dependent and I can convert it to a number :-)

Actually it is easy... seems that I had not enough breakfast coffee this
moring :-)

thank your for the help

Alex K. Angelopoulos schrieb:My preference - "convert" - is based based on wishful thinking (see below),
but I still think, MsgBox does the right thing without unduly force to
represent a boolean by a (localized) "True" or "False".
You are right. Having written tons of lines like

WScript.Echo Result, Expected, CStr( Result = Expected )

I should have known better. So I have to take back my "All display
functions ..." statement also. Some functions/subs - notably
WScript.Echo - misbehave.

Thanks for pointing out my mistake.

Inline - you can sort of recant your mistake ; )

"ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
news:4a27b378$0$32674$9b4e6d93@xxxxxx-online.net...
Good point, actually. Probably the best word is "render" - nothing happens
to the underlying data, it's simply being rendered as a localized string -
like dates.
I changed my mind while you were posting. People tend to use WScript.Echo
like MsgBox, stringing together multiple elements with & - which gives us
the same behavior, two-state value rendered as a localized string
representation:

WScript.Echo true & vbNullString

Heinz schrieb:[...][...]or possibly to a boolean

[...]Don't mention it; thank *you* for the feedback.

Alex K. Angelopoulos schrieb:I agree.
So it's the concatenation that triggers the rendering. That means
you'll have to think about that when using Join too.

Thanks again for setting me straight.