>>>Like I said, this was sometime ago, so I don't know (and haven't tested) if it still applies. I believe, however, that it probably does.
>>
>>Yes... it still works that way... also, with AND expressions, once a .f. is hit, it stops evaluating the expression... this is why you can do...
>>
>>if vartype(oObject) = "O" and oObject.Property = whatever
>>
>>If the first half is .f., and it DID try to eval the next expression, you would get an Object Not found.
>>
>Hi BOb,
>
>Of course! Don't know why I didn't think of that. Maybe I'll chalk it as "a hidden dangers of OOP". You subclass, encapsulate and then forget the underpinnings.< rbg >
>
>Regards,
I'll toss my $0.02 (US) into the ring here. Back in the dim and distant past, when real programmers used punch cards, even before Ashton met Tate <g> I learned to program in COBOL. I was taught to evaluate the likelihood of results of IF...Else.. and CASE statements so that the most likely response was the first condition tested for. Then the others followed in descending order of likelihood. I was also taught to use NOT instead of else because it offered easier readability and also clarified your logic to whoever got to maintain your code.

There is an implied difference between
i. "IF (A) then whatever ELSE (B) whatever END" and
ii. "IF NOT (A) then whatever...."

The first example implies that A is more likely to happen than B. The second example implies that A is not likely to happen. The expectation of whoever is reading your code (including you if it was long enough ago) is that in the first example that A is the norm and B is the exception. If this is not the case then whoever gets to test the code will be suprised.

This is basic logic flow and applies to all languages. It even applies to sets of written or verbal instructions we give to people. Listen to your selv next time you explain something to someone...

Jen