When is a variant true

[bbuk]

Hi

Trying to track down an elusive bug I found the following suspect statement in my program:

If .L_Serv_Lock Then lockcount = lockcount + 1

where .L_Serv_Lock is a variant which can be "0" or "1"

I have now changed this to:

If .L_Serv_Lock = "1" Then lockcount = lockcount + 1

My question is could my original form be the cause of my problem. i.e. will testing a variant in this way always give true for "1" and false for "0"?

Thanks in advance

Andy

 

[three57m]

Try
If Cbool(.L_Serv_Lock) Then lockcount = lockcount + 1

 

[JoeAtWork]

That's the trouble with variants, being that their type is ambigious. As you've seen, you have to write extra code to determine their type before you can determine their actual value.

If at all possible, I recommend declaring the variable as a specific type, such as Int or Boolean.

 

[BobRodes]

<will testing a variant in this way always give true for "1" and false for "0"?
Yes. Does .L_Serv_Lock always evaluate to one or the other?

 

[bbuk]

Hi Bob

Yes, the .L_Serv_Lock is part of a data string passed from another program and it can only be "0" or "1". I already have a verification routine to make sure the string only contains valid characters in each position. The problem I have is that the fault condition is so sporadic I can't reproduce it reliably so I am looking for strange logic errors in my routines which could cause it. I think I will fix this one anyway just as punishmnent for being lax in the first place.

Guess I'll carry on looking then...

Thanks to all for the input

Andy

 

[BobRodes]

Whether you allow VB to do implicit castings, as opposed to being rigorous about every type, is really more a matter of style. However, you may well run into squirrely problems with unintended implicit type castings, so you might be on the right track. There are two reasons not to use variants when you don't have a good reason to: they are bigger than other variables and you can lose track of what type of variable you're using. Sometimes VB performs the "wrong" implicit cast, and that can be very hard to find.

A "sort of" example ("sort of" because it's actually doing the reverse--not performing the "right" implicit cast) of this is where "2" - "2" = 0, whereas "2" + "2" = "22". The subtraction can't be performed on a string, so there's an implicit cast of each character to a double, and the result is also a double. On the other hand, the + sign is an overloaded operator; it either functions as an addition operator or a string concatenation operator, depending on the types of the operands. Therefore, it's quite happy to concatenate the two strings and return a string result.

I hope you find your intermittent logical bug. Those are about the worst kind.

Bob