Chapter 30: Using Access Macros
1075
l (^) Debug window: Use the debug window to look at any values, temporary variables, or
properties of the MacroError object after you stop the macro. Press Ctrl+G to display
the code window after you stop the macro. Just type a question mark (?) and the variable
or expression you want to check the value of, and press Enter. Here are some examples of
expressions to display in the Debug window:
? TempVars!MyNum
? MacroError!Description
? [Forms]![frmReportMenuEnhanced]![cboReport]
These techniques are similar to ones you’d use when debugging VBA code. You can step through
sections of code, pause the code and look at values in the debug window, and display message
boxes to display variables or errors that occur. Granted, you don’t have all the tools available —
such as watching variables and Debug.Print — but at least you have the new MacroError
object to provide the information you need to figure out what’s going wrong.
Cross-Reference
For more information on error handling, see Chapter 23. Debugging VBA code is covered in Chapter 14.
Embedded Macros
An embedded macro is stored in an event property and is part of the object to which it belongs.
When you modify an embedded macro, you don’t have to worry about other controls that might
use the macro because each embedded macro is independent. Embedded macros aren’t visible in
the Navigation Pane and are only accessible from the object’s Property Sheet.
As an example, let’s say you want to add a command button to a form that opens a report. You
could use a global macro (one that’s in the Navigation Pane) to open the report, or you could add
an embedded macro to the command button.
Embedded macros are trusted. They run even if your security settings prevent the running of code.
Using embedded macros allows you to distribute your application as a trusted application because
embedded macros are automatically prevented from performing unsafe operations.
One big change in Access 2007 and 2010 is that, when you use a wizard to create a button, it no
longer creates an event procedure — it creates an embedded macro. So if you’re used to running a
wizard and using the wizard’s VBA code for another purpose, you’ll have to abandon that tech-
nique. Using embedded macros instead of code accomplishes two things:
l It allows you to quickly create a distributable application.
l (^) It allows users not familiar with VBA code to customize buttons created with wizards.