8. Locals Window
You may also find situations when testing the value
of every variable when your code enters break mode that would be utterly
mind-numbing — but you still need to know the values. If you're
stepping through code and need to test the value of seven different
variables every step of the way, that's a lot of Debug.Print
statements to type and keep track of in the Immediate window. The Locals
window comes to the rescue by displaying all the variables in a
procedure along with their values. You can observe the changes in the
values of the variable as you step through the code. To display the
Locals window, select View => Locals Window. Figure 6 shows the Locals window while stepping through the procedure CoffeeTime.
As you step through the procedure, you see the
up-to-date values of all variables showing in the Locals window. The
Locals window retains the values until the last line of code has
executed. In this example, it will retain the values until you see a
message box stating, "You can purchase 100 lattes."
9. Watch Window
The next tool that we'll examine is the Watch window.
The Watch window enables you to watch a variable within your procedure.
When the value of the variable changes or when the variable is True, your code enters break mode. To open the Watch window, select View => Watch Window.
To see how the Watch window works, we will use WatchGoShoppingSuits, which is a modified version of the GoShopping
module. Recall that it uses a Boolean expression and message box to let
you know if (when) you're over budget. We will add a watch on the
variable blnOverBudget. You start by right-clicking in the Watch window and choosing Add Watch. The Add Watch dialog box opens (see Figure 7).
Enter blnOverBudget in the Expression text
box. In the Watch Type you can select one of three options: Watch
Expression (the default selection), Break When Value is True, or Break
When Value Changes. For this example, choose Break When Value Is True,
and then click OK to save your watch. When you run the SteppingThroughCodeGoShopping2 procedure, the procedure will enter the break mode when the value of blnOverBudget becomes True. As soon as the loop executes for the eleventh time, the watch expression is triggered and the code enters break mode.
If you choose to simply watch the expression (rather
than break), the Watch window behaves almost exactly like the Locals
window except that only the selected watched variables are shown.
If you have a rather long loop to execute and you no
longer need your watch, you can delete it while your code is in break
mode. Simply right-click the watch and select Delete Watch. You can then
press F5 to continue code execution.
|
A shortcut for adding a watch is to right-click the
variable and select Add Watch. The variable name is filled in
automatically, which is a great way to avoid the risk of typos.
10. Edit and Continue
The last tool that we'll cover here is Edit and Continue. In the VBA Editor options (choose Tools Options
General), you can set a feature called Edit and Continue. With only a
few limitations, this feature allows you to make changes to the code
while the program is in break mode and to apply those changes without
requiring you to end the debug session and execute the program again.
When your code halts because of an error or a
breakpoint, the VBA Editor displays the problem line or breakpoint line
with an arrow pointing to it. You may identify the issue on that line
and make the appropriate changes. When you execute that line (by
pressing F8), the line may execute correctly (as intended). However,
there will be times when you determine that the problem lies several
lines before the current break location. Fortunately, you can make the
correction and then restart the code from a location other then where it
stopped. To change the starting point, just click on the original arrow
(pointer) and drag it to the line where you want to start executing the
code.
Be aware that depending on what code was executed,
you may still not get valid results, particularly if the results are
dependent on earlier code or values. So if you think you've corrected
the problem but the code still isn't displaying the expected values, it
is typically best to rerun the entire procedure, module, or function.
You should also keep in mind that code
changes made during execution may not always be saved when the program
ends. Regretfully, there is no definitive list of all the scenarios that
might trigger a loss of changes to the code, but you can expect the
changes to be lost if running the new code causes the application to
shut down. Presumably, the logic is that you would not want to save
modifications that caused the application to crash. But it doesn't
differentiate between desired and undesired changes. So, to minimize the
extent of potential losses, we recommend that you save changes as you
go, a prudent move in most tasks associated with computers.