Back to School
Although Visual Basic 6 is certainly not the rottweiler on speed that C++ and the Microsoft Foundation Classes (MFC) can be, there is no doubt that its increased power and size come with their own dangers. Visual Basic 6 has many powerful features, and these take a while to learn. Because the language is so big, a typical developer might use only 10 percent or even less of its features in the year he or she takes to write perhaps three or four applications. It has become increasingly hard to achieve expertise in such a large and complex language. So it is perhaps no surprise to find that many bugs stem from a misunderstanding of how Visual Basic implements a particular feature.
I'll demonstrate this premise with a fairly trivial example. An examination of the following function will reveal nothing obviously unsafe. Multiplying the two maximum possible function arguments that could be received (32767 * 32767) will never produce a result bigger than can be stored in the long variable that this function returns.
Private Function BonusCalc(ByVal niNumberOfWeeks As Integer, _
ByVal niWeeklyBonus As Integer) As Long
BonusCalc = niNumberOfWeeks * niWeeklyBonus
End Function
Now if you happened to be diligent enough to receive a weekly bonus of $1,000 over a period of 35 weeks…well, let's just say that this particular function wouldn't deliver your expected bonus! Although the function looks safe enough, Visual Basic's intermediate calculations behind the scenes cause trouble. When multiplying the two integers together, Visual Basic attempts to store the temporary result into another integer before assigning it to BonusCalc. This, of course, causes an immediate overflow error. What you have to do instead is give the Visual Basic compiler some assistance. The following revised statement works because Visual Basic realizes that we might be dealing with longs rather than just integers:
BonusCalc = niNumberOfWeeks * CLng(niWeeklyBonus)
Dealing with these sorts of language quirks is not easy. Programmers are often pushed for time, so they sometimes tend to avoid experimenting with a feature to see how it really works in detail. For the same reasons, reading the manuals or online help is often confined to a hasty glance just to confirm syntax. These are false economies. Even given the fact that sections of some manuals appear to have been written by Urdu swineherders on some very heavy medication, those pages still contain many pearls. When you use something in Visual Basic 6 for the first time, take a few minutes to read about its subtleties in the documentation and write a short program to experiment with its implementation. Use it in several different ways within a program, and twist it into funny shapes. Find out what it can and can't handle.
Some final thoughts Professional developers should understand the tools at their disposal at a detailed level. Learn from the manual how the tools should work, and then go beyond the manual and find out how they really work.