Visual Basic —

A Black Box: The Instrumentation Sourcerer

When a commercial airliner experiences a serious incident or crashes, one of the most important tools available to the team that subsequently investigates the accident is the plane's black box (actually colored orange), otherwise known as the flight data recorder. This box provides vital information about the period leading up to the accident, including data about the plane's control surfaces, its instruments, and its position in the air. How easy would it be to provide this type of information in the event of user acceptance or production program bugs and crashes?

The Instrumentation Sourcerer, shown in Figure 6-4, walks through your program code, adding a line of code at the start of every procedure. This line invokes a procedure that writes a record of each procedure that is executed to a log file on disk. (See Chapter 1 for an in-depth examination of similar techniques.) In this way, you can see a complete listing of every button that your user presses, every text box or other control that your user fills in, and every response of your program. In effect, each program can be given its own black box. The interactive nature of Windows programs allows users to pick and choose their way through the different screens available to them. Thus it has traditionally been difficult to track exactly how the user is using your program or what sequence of events leads up to a bug or a crash. The Instrumentation Sourcerer can help you to understand more about your programs and the way they are used.

Figure 6-4 The Instrumentation Sourcerer dialog box

Configuration options allow you to selectively filter the procedures that you want to instrument. This might be useful if you want to document certain parts of a program, such as Click and KeyPress events. You can also choose how much information you want to store. Just as in an aircraft's black box, the amount of storage space for recording what can be a vast amount of information is limited. Limiting the data recorded to maybe the last 500 or 1000 procedures can help you to make the best use of the hard disk space available on your machine or on your users' machines.

Some final thoughts The Instrumentation Sourcerer can be useful in tracking the cause of program bugs and crashes, at the same time providing an effective record of how users interact with your program in the real world.

Final Thoughts

Is it possible to write zero-defect Visual Basic 6 code? I don't believe it is-and even if it were, I doubt it would be cost-effective to implement. However, it is certainly possible to drastically reduce the number of production bugs. You just have to want to do it and to prepare properly using the right tools and the right attitudes. From here, you need to build your own bug lists, your own techniques, and your own antidefect tools. Although none of the ideas and techniques described in this chapter will necessarily prevent you from creating a program with a distinct resemblance to a papcastle (something drawn or modeled by a small child that you are supposed to recognize), at least your programs will have presumptions toward being zero-defect papcastles.

Final disclaimer: All the bugs in this chapter were metaphorical constructs. No actual bugs were harmed during the writing of this work.

Required Reading

The following books are highly recommended-maybe even essential-reading for any professional Visual Basic developer.

  • Hardcore Visual Basic by Bruce McKinney (Microsoft Press, 1997)
  • Hitchhiker's Guide To Visual Basic and SQL Server, 6th Edition by Bill Vaughan (Microsoft Press, 1998)
  • Microsoft Visual Basic 6 Programmer's Guide by Microsoft Corporation (Microsoft Press, 1998)
  • Dan Appleman's Developing ActiveX Components With Visual Basic 5.0 by Dan Appleman (Ziff-Davis, 1997)
  • Software Project Survival Guide by Steve McConnell (Microsoft Press, 1997)
  • Code Complete by Steve McConnell (Microsoft Press, 1993)