Using the VBA Editor
The VBA Editor (see Figure 39.4) is a true work of art. It's easily the equal of any programming editor ever devised, although it also has some noteworthy shortcomings, which you'll learn about later in this section.
Figure 39.4. The VBA Editor usually contains two "dockable," resizable panes, plus a large open area for writing programs and creating custom dialog boxes.
To open the VBA Editor in Word, Excel, PowerPoint, Outlook, FrontPage, or Access, choose Tools, Macro, Visual Basic Editor. The VBA Editor sits in its own window, separate from the Office application that opened it.
Managing VBA Components with Project Explorer
Although you can drag and dock the Project Explorer window anywhere—even, surprisingly, outside the VBA Editor window—it usually sits in the upper-left corner of the VBA Editor.
At the highest level, the Project Explorer provides a list of projects. In VBA/Word, for example, that's a list of all open documents and templates. Because Normal.dot is always open when Word runs, it always appears in the VBA/Word Project Explorer as the Normal project.
Tip from 
If you want to open a new project, you must switch back to the original application—in the case of Figure 39.4, Word—and open the project's document or template. After you open the file using the correct application, the associated project appears in Project Explorer.
Renaming a macro in the VBA Editor is a snap:
Click to select the macro whose name you want to change, and click Edit.
The VBA Editor appears, with the insertion point at the beginning of the Sub line that corresponds to the macro you've chosen. For example, if you picked Macro3, the insertion point should be on the line that says Sub Macro3(), as in Figure 39.5.
Figure 39.5. If you ask to edit the macro called Macro3, you'll end up in the subroutine called Macro3().
To change the name of the macro, delete the old macro name and type in a new one. In the case of Figure 39.5, you could delete the name Macro3 and type the name ChangeToSlideView.
Tip from 
Don't worry about the parentheses after the macro name. If you forget to type them, VBA puts them in for you.
To verify that the macro name has changed—and it will change, even if you don't save the template—switch back to the application, choose Tools, Macro, Macros, and look for the new name in the list of macro names.
Although changing a macro name is easy—if you don't mind working directly with the subroutine program code—copying, moving, and deleting individual macros with the VBA Editor can be a frustrating and error-prone process.
Say you have a macro called ItalicizeFirstWord in Normal.dot's (er, "the Normal Project's") NewMacros module, and you want to move it into a new Normal.dot module called Production:
Start the VBA Editor (choose Tools, Macro, Visual Basic Editor). In the Project Explorer, navigate to the Normal project's Modules folder and click it.
Add the new module by choosing Insert, Module. A new module called Module1 appears (see Figure 39.6). (If you already have a module called Module1, each new module is called Module2, Module 3, and so on.)
Figure 39.6. When you create a new VBA module, Office gives it the generic name Module1. It's a good idea to change this name to something more descriptive.
Click Module1. In the Properties window, find the entry marked (Name), double-click to select Module1, and type Production (see Figure 39.7). Press Enter to change the name in the Project Explorer.
Figure 39.7. Use the Properties window to change the name of a module.
To retrieve the ItalicizeFirstWord macro, double-click the NewMacros module, and then scroll or use the Procedure drop-down list (see Figure 39.8) to find ItalicizeFirstWord.
Figure 39.8. To see a list of all macros in the current module, use the Procedure drop-down list.
Tip from 
It's always a good idea to rename a module as soon as you create it. Renaming modules after you've started to build a program can be difficult, because many hidden references to the module names are scattered throughout VBA programs.
Tip from 
You can switch between seeing a single procedure (Procedure view) at a time and all procedures, one after the other (Full Module view) by clicking the appropriate buttons as shown previously in Figure 39.8.
At this point, you might think there would be a way to drag and drop ItalicizeFirstWord into the Production module, but the VBA Editor isn't that smart. Instead, you have to select the entire subroutine, from the Sub ItalicizeFirstWord() line all the way through End Sub, and then choose Edit, Cut.
Double-click the Production module in the Project Explorer, and then choose Edit, Paste (see Figure 39.9).
Figure 39.9. There is no way to drag and drop macros from one module to another. Instead, use the Clipboard to cut the macro out of the NewMacros module, and then paste it into the Production module.
Other familiar Explorer-like actions aren't possible in Project Explorer, either. For example, you can't click a module and press the Delete key to delete it. Instead, you must right-click the module name and choose Remove.
Tip from 
You can click and drag within Project Explorer to copy a module from one project to another. Unfortunately, the right mouse button doesn't work the way it does in Office applications, so you can't right-click and drag to move a module, for example. (However, you can always click and drag to copy, and then delete the original.)
Programming in the Code Window
The VBA Editor's Code window houses a sophisticated development and debugging system. Among its many features:
Auto Quick Info— When typing a command in the Code window, you'll find that the VBA Editor offers ScreenTips and parameter lists (which arguments have to be provided to subroutines and functions, and in what order). They help you type faster and remember the (often lengthy) details of how each command is fashioned. Press the Tab key to accept the offered auto entry.
Stepped Execution— The VBA Editor lets you step through programs, one line at a time, and watch the results of each command. You can even "hover" the mouse pointer over a variable and the VBA Editor displays a ScreenTip that shows the current value of the variable.
→ For more details on stepped execution, see "Stepping Through and Editing Recorded Macros".
Context-Sensitive F1 Help— If you're ever stuck on a command and can't figure out what it should do, press F1 and VBA's extensive (but far from exhaustive) Help system appears.
Quick Access to Subroutines— Click the down arrow next to the Procedure drop-down list (see Figure 39.10), select a subroutine, and the VBA Editor takes you right to it.
Figure 39.10. All the procedures (subroutines and functions) in a module appear in the Procedure drop-down list.
Object Browser— Although it will take a while for you to get accustomed to it, the VBA Object Browser lets you look at all the commands available in the object models, not only for the version of VBA that you're using (for example, all the VBA/Word commands), but for other applications that you can control via VBA (such as Excel). To see the Object Browser, press F2 (see Figure 39.11).
Figure 39.11. The Object Browser lists every command available, and includes hot links at the bottom of Help file entries.
Tip from 
To make commands for other applications visible in the Object Browser, choose Tools, References and check any applications that interest you. At a minimum, consider checking the boxes for: Office, Word, Excel, PowerPoint, Outlook, the FrontPage Editor and Microsoft FrontPage Web Objects Reference, the Microsoft Windows Scripting Host, and (if you'll be working with databases) Access and DAO.
Adding applications to the References list won't seriously affect performance, although it can make lookups more difficult. If you look for the Find command, for example, and you have References for both Word and Excel, you'll have to tell the Object Browser whether you want to look up Word's Find or Excel's Find. In practice, this rarely causes a problem.
Many, but by no means all, of the applications listed include version numbers. In general, you should pick the versions of the applications you have installed on your machine (which usually means the latest versions). When you upgrade, go back into the References list, uncheck the old version, and check the new one.
If you write a program with one flavor of VBA—for example, VBA/Word—and it calls Excel, that program will run only on machines with both Word and Excel installed. Depending on the details of the program, you might actually need to run the same versions of Word and Excel that were used to develop the program. But the person running the program need not go into VBA and change the References list to add Excel. (One subtle exception to that final point: If the program contains named variables that are unique to the application—for instance, wdAlignParagraphCentered in Word, or xlToLeft in Excel—the Reference list for the affected application must be active.)
A host of programming settings appear if you choose Tools, Options. Among the most important is syntax checking (the Auto Syntax Check box), which controls whether VBA will check the syntax of every line as it is typed; and strict variable checking (the Require Variable Declaration box), which forces you to declare all your variables in Dim statements. Most experienced programmers turn the former off and the latter on—precisely the opposite of the default values.