Clarify the Muddle with the Call Stack

Initially, you probably won't have much reason to be concerned about a call stack because the procedures you'll write will likely be monolithic in nature with a few procedures. Usually these types of programs have simple relationships between procedures at run-time. As you progress, you'll write smaller, purposeful procedures and build functionality by assembling groups of procedures that collectively perform useful actions.

In assembling groups of procedures, you'll occasionally create a maze of procedural execution with one procedure calling another, which calls another, which calls yet another. As you step through code such as this, it's pretty easy to lose track of where you are in the whole scheme of things. This is where the call stack comes into play.

The call stack is a term for the list of procedures currently in scope according to the order in which they were called beginning with the most recently called procedure. Listing 4.4 demonstrates this concept.

Listing 4.4: Demonstrating a Call Stack

Sub MainProcedure() Procedure1

Debug.Print "Finishing MainProcedure" End Sub

Sub Procedure1() Procedure2

Debug.Print "Finishing Procedure1" End Sub

Sub Procedure2() Procedure3

Debug.Print "Finishing Procedure2" End Sub

Sub Procedure3()

Debug.Print "Finishing Procedure3" End Sub

Running MainProcedure produces the following output:

Finishing Procedure3 Finishing Procedure2 Finishing Procedurel Finishing MainProcedure

While in Break mode, you can view the call stack at any time by pressing CTRL+L (View ^ Call Stack...) to display the Call Stack window.

Call Stack

E

| Project, Module.Function

1 <;hâ„¢, 1 1

VBAProject, Module! ,Procedure2

Close I

VBAProject. Module 1. Procedure i

1

VBAProject. Module 3 .MainProcedure

0 0

Post a comment