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:

> 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
>

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

>> wscript.echo cstr(true)

Wahr

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

>> wscript.echo True, False, CInt( True ), cInt( False )

-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

> 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
>
>
>
>
>

Alex K. Angelopoulos schrieb:

> 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.

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).

> 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.

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.

> 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.

[...]

"ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
news:4a27a45b$0$32663$9b4e6d93@xxxxxx-online.net...

> Alex K. Angelopoulos schrieb:

>> 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.

>
> 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).

OK, artifact is a _bad_ word here; but not coerce. MsgBox really is coercing
the value to a string from what I can tell.

>> 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.

>
> 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.

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.

>> 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.

>
> [...]

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

> Heinz schrieb:

>> 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
>>

>
> 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
>

> >> wscript.echo cstr(true)

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

> >> wscript.echo True, False, CInt( True ), cInt( False )

> -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).
>

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:

>
>
> "ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
> news:4a27a45b$0$32663$9b4e6d93@xxxxxx-online.net...

>> Alex K. Angelopoulos schrieb:

>>> 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.

>>
>> 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).

>
> OK, artifact is a _bad_ word here; but not coerce. MsgBox really is
> coercing the value to a string from what I can tell.
>

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".

>>> 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.

>>
>> 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.

>
> Exactly?
> x=true
> WScript.Echo x

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.

>
> 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.
>

>>> 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.

>>
>> [...]

>

Inline - you can sort of recant your mistake ; )

"ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
news:4a27b378$0$32674$9b4e6d93@xxxxxx-online.net...

> Alex K. Angelopoulos schrieb:

>>
>> "ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
>> news:4a27a45b$0$32663$9b4e6d93@xxxxxx-online.net...

>>> Alex K. Angelopoulos schrieb:
>>>> 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.
>>>
>>> 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).

>>
>> OK, artifact is a _bad_ word here; but not coerce. MsgBox really is
>> coercing the value to a string from what I can tell.
>>

> 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".

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.

>>>> 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.
>>>
>>> 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.

>>
>> Exactly?
>> x=true
>> WScript.Echo x

>
> 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.

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:

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

>> Heinz schrieb:

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

[...]

>> 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).

[...]

> 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 :-)

or possibly to a boolean

[...]

> thank your for the help

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

Alex K. Angelopoulos schrieb:

> Inline - you can sort of recant your mistake ; )
>
> "ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
> news:4a27b378$0$32674$9b4e6d93@xxxxxx-online.net...
>

>> Alex K. Angelopoulos schrieb:

>>>
>>> "ekkehard.horner" <ekkehard.horner@xxxxxx> wrote in message
>>> news:4a27a45b$0$32663$9b4e6d93@xxxxxx-online.net...
>>>> Alex K. Angelopoulos schrieb:
>>>>> 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.
>>>>
>>>> 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).
>>>
>>> OK, artifact is a _bad_ word here; but not coerce. MsgBox really is
>>> coercing the value to a string from what I can tell.
>>>

>> 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".

>
> 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 agree.

>>>>> 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.
>>>>
>>>> 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.
>>>
>>> Exactly?
>>> x=true
>>> WScript.Echo x

>>
>> 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.

>
> 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

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.