Pausing at a Problem Statement

To use most of the Microsoft Access debugging tools, you need to suspend execution of your code. In the suspended state, the code is still running but paused between statements. Variables and property settings retain their values, and the Module window displays the code that is currently running.

If you suspect that the problem you're trying to uncover occurs at a certain place in the code, you'll probably want to suspend execution at that location. To make Visual Basic pause execution of your code, you can use one of the following procedures:

Set a breakpoint on a given line. A breakpoint is a statement at which Visual Basic automatically suspends execution.

See Also For more information on breakpoints, see the following section, "Using a Breakpoint."

Use a Stop statement on a given line.

See Also For more information on the Stop statement, see "Using a Stop Statement" later in this chapter.

Press CTRL+BREAK while the code is running.

Visual Basic also suspends execution at a given line if a statement on that line generates a run-time error. However, this is true only if no error trapping is in effect at the time the error occurs.

Note If your Microsoft Access workgroup has security enabled (if you logged on by using the Logon dialog box), you must have Read Design permission for a module in order to suspend code execution within that module. If you don't have Read Design permission for the module that contains the code, and you run code that contains a Stop statement or produces a run-time error, Visual Basic gives you the choice of continuing execution or resetting the code. If you press CTRL+BREAK while code is running, Visual Basic suspends execution at the first statement in a module for which you do have Read Design permission. For information on permissions and security, see Chapter 14, "Securing Your Application."

Using a Breakpoint

When Visual Basic encounters a breakpoint while running a procedure, it suspends execution just before running the breakpoint line. Set a breakpoint at any point in your code where you want to monitor what's really going on behind the scenes. For example, if you want to verify that a certain section of code is setting variables as you expect, set a breakpoint on a line of code at the beginning of the section.

You can set or clear a breakpoint when you are writing code in the Module window or when execution is suspended. When execution is suspended, Visual Basic displays the breakpoint and surrounding lines of code in the Module window.

To set or clear a breakpoint

In the Module window, click the left margin next to the line of code on which you want to set or clear the breakpoint.

When you set a breakpoint, Visual Basic displays the breakpoint indicator (a red circle) in the margin to the left of the line on which code will pause and displays the text of the line as white text on a red background. For example, the third statement of the procedure in the following illustration is a breakpoint.

Visual Basic displays a yellow arrow in the margin to the left of the statement at which the procedure is suspended and displays the statement inside a box with a yellow background. This arrow and yellow box indicate the current statement, or the next statement to be run. When the current statement also contains a breakpoint, both the breakpoint and current statement indicators are displayed overlapping in the margin. In the procedure in the preceding illustration, one Step Into command has been carried out after reaching the breakpoint, and the fifth line is the current statement.

Once a breakpoint is reached and the code is suspended, you can examine what has happened up to that point by inspecting variables and objects in the Debug window, by switching between the Debug window and the other windows in your database, and by using other debugging strategies described in the remainder of this chapter.

If the problem you're trying to solve has already occurred, then you know a line of code that has already run is causing the problem. If the problem hasn't already occurred, then a line of code that has not yet run is causing the problem. If the breakpoint line is the cause, the problem won't occur until you run at least one more statement. Once execution has been suspended, you can step through your code line by line to find the problem.

See Also For more information on stepping through code line by line, see "Stepping Through Statements" later in this chapter.

Important The problem may not be a line of code. A statement can be the indirect cause of the problem if it assigns an incorrect value to a variable. You can examine the values of controls, properties, and variables while execution is suspended. For more information, see "Using the Immediate Pane" later in this chapter.

Using a Stop Statement

As an alternative to setting a breakpoint, you can put a Stop statement in a procedure. Visual Basic suspends execution whenever it encounters a Stop statement. In effect, a Stop statement is a breakpoint, but it's more permanent. If you close the database or quit Microsoft Access, all breakpoints are cleared. Stop statements stay in the code until you remove them.

See Also For more information on the Stop statement, search the Help index for "Stop statement."

Continuing Execution After a Run-Time Error

Some run-time errors result from simple oversights when you enter code and can be easily fixed. Suppose, for example, that you want your application to disable the Details command button on the Orders form in the Orders sample application when the form opens. But instead of adding code in the form's Load event procedure that sets the control's Enabled property to False, you add code that tries to set the control's nonexistent Locked property to True.

Forms!Orders!Details.Locked = True

The code produces a run-time error when you open the Orders form, as shown in the following illustration.

In this case, the solution is to fix the problem statement so that it uses the correct property and setting.

Forms!Orders!Details.Enabled = False

After you've changed the code that caused a run-time error, you can continue running your application from the point where execution was suspended. To continue running your application, click the Go/Continue button on the toolbar. The Orders form opens as expected with the Details command button disabled.

Some changes, most commonly changes in variable declarations, require the code to be reset. When this is the case, Visual Basic displays a message and gives you the option of continuing without the change or accepting the change and resetting the code.

Casa de Bender