VBA Support in Outlook

Outlook 2000 and later supports VBA. Now, you might be thinking that your Outlook forms already support VBA, but this is not the case. In fact, you still need to write VBScript behind your Outlook forms. VBA support in Outlook provides a way to customize the Outlook environment using the Outlook object model and all the events just discussed without using a separate development tool such as Visual Basic.

VBA Architecture

When you write your VBA applications in Outlook, you must contain your code in a VBA project. Each project is associated with a particular user, which means that different users on the same machine can customize Outlook differently using VBA. These projects can contain code modules or user forms. (User forms are different from Outlook forms.) To share information among these VBA projects, you must export your file and have the receiving user import your file into her VBA project.

Creating a VBA Application

The first step in creating a VBA application is to launch the Visual Basic Editor in Outlook. From the Tools menu, choose Macro. The Visual Basic Editor appears, as shown in Figure 7-11. You can use the editor to add class modules, code modules, and user forms, depending on the needs of your application. You can even write code that responds to Outlook events by declaring your variables using the WithEvents keyword.

Figure 7-11: The Visual Basic Editor in Outlook

The Outlook object model is automatically available to your VBA application. After you finish writing your macro in the editor, you can explicitly run it or create a button on your Outlook toolbar that runs the macro when clicked. Figure 7-12 shows a sample application that converts incoming mail to a specific message class using a VBA macro and the Outlook object model.

Figure 7-12: The sample mail conversion code in the Visual Basic Editor

Choosing What to Write: COM Add-In or VBA Program?

By now you must be wondering whether you should write VBA programs or COM add-ins to customize your Outlook environment. Both technologies have their merits, but if more than one user will run your program in an Outlook client, you should write a COM add-in. COM add-ins are easily distributed, and you can control a user's ability to run them.

If you want to customize only the Outlook client, writing a quick VBA program is easier than writing a full-blown COM add-in. To deploy your application in VBA, however, users must import the VBA file into their Outlook client, which is not the best deployment method. I predict that if you use COM add-ins, many users will install your application.