Outlook 2000 supports VBA. Now some of you reading this book 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. The VBA support in Outlook provides a way to customize the Outlook environment using the Outlook object model and all the new events just discussed without using a separate development tool such as Visual Basic.
When writing your VBA applications in Outlook, all your code is contained in a VBA project. Each project is associated with a particular user. This 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.
The first step in creating your VBA application is to launch the Visual Basic Editor in Outlook. You can find the Visual Basic Editor on the Tools menu, via the Macro option. The Visual Basic Editor is shown in Figure 9-10. Once you are in the editor, you can 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.
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 9-11 shows a sample application that converts incoming mail to a specific message class using a VBA macro and the Outlook object model.
Figure 9-10 The Visual Basic Editor in Outlook 2000. From here, you have the full power of VBA for your application.
Figure 9-11 The sample mail conversion code in the Visual Basic Editor.
By now you must be wondering whether you should write VBA programs or COM add-ins to customize your Outlook environment. While both technologies have their merits, I believe that if more than one user is going to 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 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 recommend that you use COM add-ins many users will be installing your application.