Powerful PowerPoint for Educators: Using Visual Basic for Applications to Make PowerPoint Interactive

Testing for Bugs
There are two main types of bugs: (1) those that cause your script not to
work, and (2) those that cause your script to work but not work prop erly. The
first type is easy to detect be cause you will either get an error message or noth ing
will hap pen (see below). The second type is much harder to de tect be cause ev -
erything will ap pear to work fine, but the results you get will not be right (e.g.,
the computer tells you how many ques tions were an swered correctly, but the
number it gives is not the right num ber). Both kinds of bugs require you to test
your pro ject to make sure it is working properly.
When you write a pro cedure, you should try to tie it to a but ton as soon as
possible. Then go to Slide Show View and click on the but ton. If you get an error
message or, more likely, noth ing hap pens, you know you have a prob lem. This is
probably the first type of error, and you can go back to your script to find out
what is wrong.
If something hap pens, but it is the wrong thing, you know you have a prob -
lem. This is the second type of error. Unfortunately, the second type of error is
usually harder to spot and re quires much more extensive testing as well as pay -
ing close attention to what happens. For something as simple as the
DoingWell
procedure, it might be easy to see that you have a problem, but this pro cedure re-
lies on the 
YourName
pro cedure to give it the correct an swer. If 
DoingWell
brings up a
MsgBox
with “You are do ing well,” and no name, there is a prob lem,
but where is it? Before you even track down where the prob lem is, you must
154 De bug ging Tips

---

notice that a prob lem ex ists. If you are not paying close attention, you will see a
MsgBox
pop up, but you will not no tice that anything is wrong.
As our pro cedures be come more and more complicated and more and more
interdependent, spotting a problem can be very difficult. If a pro cedure isn’t tied to a 
button but called from another procedure, you can’t simply tie the pro cedure to a
button and expect it to work. A procedure that de pends on other things hap pening
first is hard to test. If you tie 
DoingWell
to a but ton and click on the but ton, you
might not get the results you ex pect, but it might be because something is wrong, or
it might be because you haven’t clicked on a but ton that is tied to 
YourName
yet.
This could be because some of your pro cedures are written in correctly, you are test-
ing out an isolated pro cedure before putting the whole presentation to gether, or you
didn’t force the student to type a name before moving through the pre sentation.
This is an example of why thor oughly testing your pro cedures is very im-
portant. If you create a presentation, you know what you are sup posed to do. If
you al ways do what you are sup posed to do and ev erything works, you know the
project works when your stu dents al ways do what they are supposed to do. Do
your stu dents al ways do what they are supposed to do? Of course not. They will
get answers wrong. They will click on one but ton when you gave them direc-
tions to click on an other button first. They will use arrow keys and the space bar
to move to the next slide if you forgot to put your presentation in Kiosk mode.
They will click the same button fifty times in a row, just to hear the sound that
the wrong-answer but tons make. In short, they will not do everything right, and
when you are testing your program, you should not either.