Microsoft Access 2010 Bible

Chapter 14: Debugging Your Access Applications

549

you’ll put the function into a single module, declare it with the Public keyword so that it’s recog-

nized and used by the entire application, and then call it from whichever procedure needs a sales

tax calculation.

Furthermore, imagine that this application has many such functions and subroutines, each calling

the other, depending on the application’s logic at that moment. Finally, imagine that users report

that the shipping fee appears to be incorrectly calculated under some conditions but not others.

You could single-step through all the code in the application, hoping to discover the cause of the

erroneous shipping fee. However, this approach wouldn’t be efficient. You’d be much better off

setting a conditional watch on an important variable within the shipping fee function, forcing the

code to break when the condition is True. Then open the Call Stack window (see Figure 14.25) to

view the path that the VBA engine has taken to reach this particular point in the code.

FIGURE 14.25

The Call Stack window shows you how the execution point reached its current position.

The bottom entry in the Call Stack window ([[Collectible Mini Cars]].basCall-

Stack1.Procedure1) indicates that Procedure1 (contained in module basCallStack1)

was the first function called. The entry above it ([[Collectible Mini Cars]].basCall-

Stack2.Procedure2) indicates that Procedure1 call Procedure2 (contained in basCall-

Stack2) and so on. You can quite easily trace the path that the VBA code has taken to reach the

current breakpoint.

Double-click on any of the items listed in the Call Stack to be taken to the statement that sent exe-

cution to the next procedure. Using the Call Stack window in conjunction with conditional

watches enables you to stop code wherever relevant, and to diagnose how code has executed up to

the breakpoint.

Summary

This chapter takes a quick look at the important topic of debugging Access VBA code. The tech-

niques you apply and the tools you use in debugging your code are highly individual choices. Not

all developers feel comfortable using the Immediate window to watch variables. Not every devel-

oper uses breakpoints and the Step buttons to stop and control execution. At the same time, it’s

nice to know that these tools are available for you to use when you’re ready!