Design-Time Tools

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

The Visual Basic Editor has several features that can help you debug your code. You specify whether these features are turned on by clicking Options on the Tools menu, clicking the Editor tab, and then selecting the features you want under Code Settings. Turning on all these settings can make it easier to debug code. The Require Variable Declaration option is probably the most important because, when it is selected, the Option Explicit statement is inserted in the first line of any module you create, including those for forms, reports, and Microsoft® Office documents. The Option Explicit statement forces you to declare every variable you use and prevents one of the most common sources of hard-to-find bugs: misspelled variable names.

The Auto Syntax Check option specifies whether the Visual Basic Editor will check each line of code for errors as soon as you have finished writing the code. If this option is not selected, the Visual Basic Editor still will check the syntax of all your code before you can compile or run it.

The Auto Data Tips option specifies whether you can view the data contained in a variable while in break mode by resting the mouse pointer on the variable name.

The Options dialog box contains another important set of options that can make debugging easier. On the General tab, there is an Error Trapping section where you can specify what will happen when an error occurs in your code.

You will want to select different options in the Error Trapping section depending on where you are in the debugging process. The default setting is Break on Unhandled Errors. This setting makes it easier to debug error handlers because you can step through the code as it enters the error handler in all circumstances.

Generally, you will want to select the Break on Unhandled Errors option. However, when you are debugging code in class modules, you will want to select the Break in Class Module option so that you can identify the offending line of code in the class module. Otherwise, an error in a class module will cause code to break in the procedure that called the class module rather than in the class module itself. If your application has no class modules, selecting Break in Class Module has the same effect as selecting Break on Unhandled Errors.

For more information about the options available in the Options dialog box, click the tab that contains the option you are interested in, and then click the Help button.

Viewing Code after Errors in Microsoft Access

In previous versions of Microsoft® Access, you could prevent users from entering break mode when errors occurred by clearing the Allow Viewing Code After Error****check box in the Startup dialog box (Tools menu). This setting did not actually secure code modules, but the option to view code was disabled when errors were encountered so that code could not be viewed easily. Because of changes in how Microsoft® Visual Basic® for Applications (VBA) is integrated into Access, the option to view code when errors are encountered is no longer available. However, you can prevent all unauthorized users from viewing your code under any circumstances by locking your application's VBA project.

See Also

Writing Error-Free Code | Run-Time Tools | Script Debugging Tools | Additional Debugging Techniques | Handling Errors