Using Break Mode

See Also

At design time, you can change the design or code of an application, but you cannot see how your changes affect the way the application runs. At run time, you can watch how the application behaves, but you cannot directly change the code.

Break mode halts the operation of an application and gives you a snapshot of its condition at any moment. Variable and property settings are preserved, so you can analyze the current state of the application and enter changes that affect how the application runs. When an application is in break mode, you can:

• Modify code in the application.
  
  
• Observe the condition of the application's interface.
  
  
• Determine which active procedures have been called.
  
  
• Watch the values of variables, properties, and statements.
  
  
• Change the values of variables and properties.
  
  
• View or control which statement the application will run next.
  
  
• Run Visual Basic statements immediately.
  
  
• Manually control the operation of the application.

Note   You can set breakpoints and watch expressions at design time, but other debugging tools work only in break mode.

Entering Break Mode at a Problem Statement

When debugging, you may want the application to halt at the place in the code where you think the problem might have started. This is one reason Visual Basic provides breakpoints and Stop statements. A breakpoint defines a statement or set of conditions at which Visual Basic automatically stops execution and puts the application in break mode without running the statement containing the breakpoint. See "Using Stop Statements" later in this chapter for a comparison of Stop statements and breakpoints.

You can enter break mode manually if you do any of the following while the application is running:

• Press CTRL+BREAK.
  
  
• Choose Break from the Run menu.
  
  
• Click the Break button on the toolbar.

It's possible to break execution when the application is idle (when it is between processing of events). When this happens, execution does not stop at a specific line, but Visual Basic switches to break mode anyway.

You can also enter break mode automatically when any of the following occurs:

• A statement generates an untrapped run-time error.
  
  
• A statement generates a run-time error and the Break on All Errors error trapping option has been selected.
  
  
• A break expression defined in the Add Watch dialog box changes or becomes true, depending on how you defined it.
  
  
• Execution reaches a line with a breakpoint.
  
  
• Execution reaches a Stop statement.

Fixing a Run-Time Error and Continuing

Some run-time errors result from simple oversights when entering code; these errors are easily fixed. Frequent errors include misspelled names and mismatched properties or methods with objects — for example, trying to use the Clear method on a text box, or the Text property with a file list box. Figure 13.11 shows a run-time error message.

Figure 13.11   Run-time errors halt execution

Often you can enter a correction and continue program execution with the same line that halted the application, even though you've changed some of the code. Simply choose Continue from the Run menu or click the Continue button on the toolbar. As you continue running the application, you can verify that the problem is fixed.

If you select Break on All Errors from the Default Error Trapping State option group on the General tab on the Options dialog box (available from the Tools menu), Visual Basic disables error handlers in code, so that when a statement generates a run-time error, Visual Basic enters break mode. If Break on All Errors is not selected, and if an error handler exists, it will intercept code and take corrective action.

Note   When you change the Default Error Trapping State option via the Options dialog box, this setting becomes the default for all subsequent sessions of VB. To change error handling for just the current session, select Toggle from the code window context menu to open a submenu that allows selection of the break mode.

Some changes (most commonly, changing variable declarations or adding new variables or procedures) require you to restart the application. When this happens, Visual Basic presents a message that asks if you want to restart the application.