This chapter is from the book

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).