Here, however, is a perfect example of something completely illogical that is perfect as a first example for this blog. We bumped into this little oddity a few years ago at work during my main day job as a Visual Basic 6 programmer.
Something I would like to achieve with this blog is to allow even non-techies, non-computer people, non-programmers, a chance to understand what I'm talking about. Now, I won't always be able to do this, but I'm hoping that this post can be an example of one that can be understood by someone who can be logical, even if they don't know the first thing about programming.
On that note, here's some VB6 program code ;) We found this bizarre bug in some components written by a third-party supplier and wrote this sample to illustrate the bug to them...
Private Sub Form_Load()
TestControl.Locked = True
Debug.Print "TestControl.Locked", TestControl.Locked
Debug.Print "Not TestControl.Locked", Not TestControl.Locked
Debug.Print "TestControl.Locked = True", TestControl.Locked = True
Debug.Print "TestControl.Locked = False", TestControl.Locked = False
Debug.Print "TestControl.Locked <> True", TestControl.Locked <> True
Debug.Print "TestControl.Locked <> False", TestControl.Locked <> False
Debug.Print "CInt(TestControl.Locked)", CInt(TestControl.Locked)
Debug.Print "CInt(True)", , CInt(True)
Now, what we've done there, is set something to True. We've then printed the value of the thing we set to True in various ways - specifically, we've asked, "What is it?", "What isn't it?", "Is it True?", "Is it False?", "Is it not True?", and "Is it not False?", and (a techy one) "What is the behind-the-scenes numerical value of it?"
Here's what we got:
Not TestControl.Locked True
TestControl.Locked = True False
TestControl.Locked = False False
TestControl.Locked <> True True
TestControl.Locked <> False True
So, what does that tell us?
Well, it tells us that:
Yes, it is True. Yes, it is not True. It's equal to True. It's equal to False. It's not equal to True. It's not equal to False.
Got that? ;) No, neither had we ;)
I told you it would be illogical ;)
The Science Bit
We can actually get some insight as to why this happened thanks to the final two things we thought to try in our test program. The CInt() function (Convert to Integer) forces our True/False value to be displayed as a number (i.e. an Integer)
True and False typically equate to 1 and 0, on and off, yes and no.
Visual Basic 6, however, treats "-1" as "True" (as we can see from the last line above) and everything else as "False". We can see that, rather than being "-1" as we would expect the value of the Locked property to be, it has actually been set to "1". This is likely to be a bug inside the third-party component where "True" has been treated as "1" at some point, and it's somewhere after that that the world has stopped making sense...