Debugging COM Add-Ins

Debugging your add-in using Visual Basic 6.0 is easy. All you do is write your add-in, register it, set some breakpoints on the code statements you are interested in, and then run the add-in in the Visual Basic 6.0 development environment. In the Project Properties dialog box for your Visual Basic project (shown in Figure 7-5), you can set some debugging options. You can specify whether to wait for the component to be created by the host application or to have Visual Basic start an instance of the host application for you. I usually specify waiting for the components to be created by the host application. After Outlook starts and creates the COM add-in, the code in the add-in executes and stops on breakpoints it encounters. You can then step through your code in the Visual Basic Editor.

Figure 7-5: The Debugging tab of the Project Properties dialog box in Visual Basic 6.0

When you debug, be aware that message boxes in your add-in will appear in the Visual Basic development environment, not in Outlook. If Outlook stops responding, you should switch to Visual Basic to see whether a message box is visible and waiting for you to respond.

Important  

In your COM add-ins, watch out for references to Inspector or Explorer objects in your code. If you do not properly destroy your variables , Outlook will exit but will stay in memory. Even if in your OnBeginShutdown procedure you set the variables holding references to these objects to Nothing , Outlook will still stay in memory. For this reason, the Explorer and Inspector objects both implement a Close event. You should add code, such as code that loops through the Explorers and Inspectors collections, to explicitly close each object to this event to destroy your references and check for any remaining Explorer or Inspector objects. If you find no Inspector objects and only one Explorer object, it's a sign that Outlook is properly shutting down.