Employing the Call Stack
The word call originates from the assembly language instruction of the same name. VBA still allows you to type Call before the name of the procedure. In a very technical sense, a call instruction indicates to the computer that the Code Segment and Instruction Pointer registers in the CPU need to begin processing the instructions at the address indicated by the CS:IP address (this is a 16-bit address, but essentially the same thing occurs in 32-bit Windows, too). A stack frame is created for allocating local variables, the current CS:IP address is stored on the stack, and local variables are allocated just after the call cs:ip instruction occurs. This is nuts and bolts assembler stuff.
For our purposes, call means the same thing, but we understand it simply to mean "go and execute the procedure named in the code." Because the call is indicated by name (and address), the debugger can examine the call stack to look at all the locations in which a procedure was called. This list of calls is referred to as the call stack. In the Visual Basic editor, you can view the call stack, as shown in Figure 3.9.
Figure 3.9 The Call Stack dialog showing the most recent procedure called, followed by the next most recent. It enables you to follow the actual operation of your program.
Why would you want to use a call stack? The answer is, if you run into trouble, it is often helpful to be able to deduce exactly the flow of control your program is following to determine where an error has occurred. From Figure 3.9, you can see that procedures are listed from most recent to least recent. Like Hansel and Gretel with their breadcrumbs, you can backtrack to figure out where your program went awry.
To backtrack to any location in your code, simply double-click an item in the Call Stack dialog, and the editor will reposition the cursor to the location in your code where the branch occurred (that is, where the call occurred).