Because this chapter and the previous one should have answered most of your questions about COM add-ins, the following list of frequently asked questions is not complete. It does, however, provide further insight based on the examples and information given in this chapter.
Q: Can a COM add-in be loaded at startup in one Office application and loaded on demand or no-load behavior in another?
A: COM add-ins are registered for each application. When you register a COM add-in for each application, you specify the LoadBehavior value in the registry. For one application, you can set the LoadBehavior value under the application's AddIns key in the Windows registry to boot-loaded (or a value of 3), while you can set the LoadBehavior value under another application's AddIns key to load on demand (or a value of 9).
Q: If a COM add-in targets more than one Office application, can you add a menu item to one application but not another?
A: When the OnConnection procedure is called after Office loads an add-in, the code in the OnConnection procedure can distinguish the application into which the COM add-in is loaded. Using the Application object passed into the OnConnection procedure, you can use the Name property to distinguish the application and determine if command bar customizations should be added. The OnConnection procedure in the COM add-in may appear as follows:
Private Sub IDTExtensibility2_OnConnection( _ ByVal Application As Object, _ ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _ ByVal AddInInst As Object, custom() As Variant) Select Case Application.Name Case "Microsoft Word" ' Do not add custom menu item Case "Microsoft Excel" ' Add custom menu item End Select End SubQ: Can I use the add-ins I created in Office 97 in Office 2000, or should I migrate my Office 97 add-ins to COM add-ins in Office 2000?
A: The COM add-in model coexists with the add-in models provided by each individual Office 97 application. You don't need to rewrite your Office 97 add-ins. They should run without modification in Office 2000. If you want to create an add-in that works in both Office 97 and Office 2000, the only way to do it is to create your add-in in Office 97 and install it in Office 2000. If your add-in is specific to Office 2000, it's recommended that you use the COM add-in model based on the table in the section "Why Should You Develop COM Add-Ins?" earlier in this chapter.
Q: How does Office know that a COM add-in works in multiple applications?
A: A COM add-in registers itself for the applications it can be connected to. This is done through the registry key HKEY_CURRENT_USER \Software\Microsoft\Office\<app>\Addins, where <app> represents any one of the Office 2000 applications, including FrontPage.
Q: Why isn't the registry key for COM add-ins located under the Office\9.0 key?
A: The majority of add-ins are written to be version independent. When you install an add-in for Office 97, you expect it to run without modification if you upgrade to Office 2000. When add-ins are installed under a specific version of Office, Office has to transfer these keys when a newer version of Office is installed. In addition, because an add-in from a previous version can be installed after Office 2000 is installed, the add-in will register itself under the specific Office version key. Therefore, Office always needs to read the previous version's key as well as the current version's key.
This introduces a performance impact, because Office has to read several keys to build its list of available add-ins for a particular application. The version-independent COM add-in keys leave it up to the developer to add code in the OnConnection procedure of the COM add-in to determine the version of the application—if the add-in is written for a specific version of Office. You can use the Version property on the Application object in each Office application. If the add-in should not be loaded in a specific version, you can add the line AddInInst.Connect = False in the OnConnection procedure.
Q: In Word, the command bar customizations that were modified or removed in the OnDisconnection procedure reappear unmodified the next time Word is started. Why aren't the customizations removed?
A: When Word shuts down, the OnDisconnection procedure is called after Word has saved changes to the Normal template and any other templates that contain command bar customizations. In the OnDisconnection procedure, you need to explicitly save the template that contains the command bar customizations. To save changes to the Normal.dot template, add the line appWord.NormalTemplate.Save (where appWord represents a variable assigned to the Word Application object) to ensure that the modification or removal of command bar customizations persist before Word quits.