ralph
3/5/2012 4:55:00 PM
On Mon, 05 Mar 2012 10:18:44 -0500, Jim Mack <no-uce-ube@mdxi.com>
wrote:
>> What would you expect from the following code.
>> No peeking now. Thought experiment only.
>>
>> Select Case True
>> Case 0
>> Debug.Print "0"
>>
>> Case 1
>> Debug.Print "1"
>>
>> Case True
>> Debug.Print "True"
>>
>> Case Else ' I was trained to put this here no matter what
>> ' Supposed to make me think that I considered this case.
>> End Select
>
>As other have pointed out, that's not the way you'd use the construct,
>even if you allow that it's a reasonable one. In order to be useful and
>coherent, the individual cases should evaluate to or be explicitly
>coerced to Boolean (CBool), or the test variable coereced to Integer /
>Long. As written it depends on implicit conversions, which the
>experienced avoid wherever possible.
>
>In any event, it's plain that since a rearrangement of the terms will
>produce a different result, it's not a good choice for casual use. It
>may be useful, but only if you completely understand its limitations.
As no one has pointed it out yet, I'll add that "VB's True = -1".
Also VB has no 'true' logical operators, everything is actually
"bit-wise". However, in its control and conditional statements ETC
tends to treat all "non-zero" results as 'true'. Which leads to the
common seemingly contradictory ...
value = 1
If value Then
Debug.Print "Value is True" ' value is certainly true enough
End If
If value = True Then
Debug.Print "Value is True"
Else
Debug.Print "Value is False" ' 1 doesn't appear to equal -1
End If
The latter test can even be more interesting in situations where
'value' is a Variant. VB will quite helpfully change the Type from
CInt/CLng to CBoolean, or vice versa. ie, either result is possible.
Other places where trouble may be brewing is ...
Do While value <> True
Never mix scalar values with Boolean values. Your assumptions might be
correct 99% of the time, but that 1% will kill you - usually around
3am in the morning. <bg>
-ralph