| Microsoft Office 2000/Visual Basic Programmer's Guide | |
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 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 will still 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.
Most of the time 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 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.
In previous versions of 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 can't be viewed easily. Because of changes in how VBA is integrated into Access 2000, 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. For more information about locking a VBA project, see "Protecting Your Solution's VBA Code" in Chapter 17, "Securing Office Documents and Visual Basic for Applications Code."