Word Document Properties

Chapter 2: Your First VBA Program
06_046500 ch02.qxp 12/5/06 5:33 PM Page 37

---

Step 3: Test, test, test
It’s time to run the application for the first time. The easiest way to run an
application is to click the Run Sub/User Form button on the Standard toolbar
in the Visual Basic Editor. (It’s the one that looks like the Play button on a VCR.)
Click the button to see the first message box. It should look like the one
shown in Figure 2-3. If the program won’t run, use the appropriate procedure
in the “Starting the Visual Basic Editor” section of Chapter 1 to set macro
security.
The message box contains the title, message, and buttons that you asked
VBA to display in the code. Checking the contents of the message box to
verify that it contains everything that you thought it would contain is 
testing.
If you want to ensure that your program always works the way you originally
designed it, you need to test as many features as possible.
Click Yes to see another message box like the one shown in Figure 2-4. Look at
the code again. Notice that this message box contains the result (the return
value) of the 
MsgBox
function. The number 6 isn’t very useful to humans, but
it’s quite usable for the computer. An actual program converts this number to
something that humans can understand. For now, you know that clicking Yes
produces a number 6.
Figure 2-4:
The
MsgBox
function
return value.
Figure 2-3:
The first
message
box asks the
user to click
a button.
38
Part I: An Overview of VBA 
06_046500 ch02.qxp 12/5/06 5:33 PM Page 38

---

When you click OK, the program ends, and you don’t see any other message
boxes. This condition verifies that the last step of the pseudo-code is complete.
Don’t assume that the testing process is over; there are two other buttons
on the initial message box. Unless you test the buttons, you won’t know that
they work. Run the program again, but try the No button the second time and
the Cancel button the third time.
The return value displayed in the second message box (refer to Figure 2-4)
should change for each button. Clicking No should produce a value of 7, and
clicking Cancel should produce a value of 2. If you don’t see these values,
your program has an error. Professionals call a programming error a 
bug.
Step 4: Swat the bugs
Bugs can appear when you test your program. Planning and writing your
code carefully reduces the number of bugs, but everyone makes mistakes.
It’s often a matter of not understanding how a function works. Testing your
programs helps you find the bugs. After you find the bugs, you have to look
at your code and discover the coding errors that create the bugs.
Not every bug is even your fault — it could be an error in the documentation
for the function. Microsoft is well known for committing mistakes of this sort
and then telling everyone that they were intentional. (Microsoft is fond of
calling these mistakes 
undocumented features.
) You might find that a bug isn’t
actually in your program but is somewhere in VBA itself. Microsoft might tell
you about these errors, but it often leaves them as surprises for you to discover.
Microsoft won’t knock on your door to tell you that it made a mistake.
You have to search for these errors on your own at a central Web site that
Microsoft has set up. The Microsoft 
Knowledge Base
is a special kind of
search engine that helps you find information about problems with VBA
and their associated fixes. You can find the Microsoft Knowledge Base at
http://search.support.microsoft.com/search/default.aspx
.
You must get rid of as many bugs as possible in your program. This task is so
important that I devote an entire chapter to it: In Chapter 6, I provide details
on how to locate and fix bugs in your program. Chapter 6 also tells you how
to keep the user from making mistakes by detecting the error before the pro-
gram does. The important idea for this chapter is that you need to fix bugs in
your application; don’t worry too much about the precise details for this task
right now.
39