If you buy a hair dryer in North America and you travel to Europe, you need to buy an adapter so you can plug it in and use it there. The hair dryer can't plug in and work in all areas of the world.
In Office 97, an add-in that plugs into Microsoft Word can't readily be plugged into Microsoft Excel or any other Office application. You need to develop an "adapter" to plug an add-in for one Office 97 application into another. In Office 2000, the COM add-in model provides the universal adapter to plug any add-in into any Office application.
The COM add-in model supersedes the capabilities of the add-in model provided by each Office 97 application. Because the COM add-in model supersedes Office 97 capabilities, if you've developed add-ins for Office 97, you'll have the option of using the COM add-in model in Office 2000 without sacrificing functionality.
IMPORTANT
There's one exception where the COM add-in model doesn't supersede Office 97 capabilities. You can't use a COM add-in to extend the list of user-defined functions in Microsoft Excel 2000 that users can enter on worksheets and evaluate. In Excel 97 and Excel 2000, you can still use Visual Basic for Applications code in an XLA file or C/C++ code in an XLL add-in file to extend the list of user-defined functions. See the Microsoft Excel 97 Developer's Kit for more information about user-defined functions.
The following table lists the characteristics that make an add-in model for Office successful. Each characteristic is available in the COM add-in model for Office 2000 and is not consistently available in Office 97. These characteristics all provide reasons why you should use the COM add-in model to create add-ins in Office 2000.
| Characteristics of an Office Add-In Model | Remarks |
|---|---|
| Teaches you how to write an add-in once and apply skills to any application | Each Office 97 application, except Outlook, has at least two ways to extend its capabilities through add-ins. In Office 2000, when you learn how to create a COM add-in once, you've learned how to create it for any Office application. |
| Allows you to write code in one file and load it into any Office application | The registration of a COM add-in indicates which Office application the add-in file can be loaded into. |
| Add-ins are easily portable to other Office applications | Using the COM add-in model, you can add an additional Select Case statement where applicable to distinguish which application the add-in is loaded into. |
| Allows you to use the programming language or developer tool you like | When Office loads a COM add-in, it doesn't know what programming language was used to build the add-in file. In Office 97, each application connects and disconnects an add-in in a different way based on the programming language the add-in is developed in. |
| Can set an add-in's connection to optimize performance | Word and Microsoft PowerPoint don't provide a way to load an add-in on demand (that is, when a menu or toolbar customization is clicked). Excel and Microsoft Access do, but in inconsistent ways. COM add-ins provide a consistent way to connect an add-in at application startup or when a user clicks a menu or toolbar customization. |
| Allows a registering of add-ins in the Microsoft Windows Registry that's consistent across applications | Each Office 97 application provides a different way and a different Windows Registry key to register an add-in. The keys to register a COM add-in are consistent in each Office 2000 application. |
| Provides a consistent and simple way to communicate between two add-ins PowerPoint's | In Office 97, Word, Excel, PowerPoint, and Access each provide the Run method on the Application object. However, method varies slightly. With COM add-ins, you can communicate between add-ins consistently using the Object property on the COMAddIn object. |
| Shows one way to learn how to package and deploy an add-in | The Package and Deployment Wizard, available in Visual Basic 6.0 or Microsoft Office 2000 Developer, provides a consistent way to package and deploy a COM add-in. |
| Can create add-ins that know if an Office application is started from the Windows Start menu or Windows Explorer, through Automation using CreateObject, or through an embedded object | A value from 1 to 3 is assigned to the first value of the custom() array argument passed into the OnConnection procedure in a COM add-in, indicating how the Office application is started. Add-ins in Office 97 don't provide a way to determine how the application is started. |
| Allows you to determine if an add-in is loaded when the application is started or after it's started | By using the ConnectMode argument passed into the OnConnection procedure in a COM add-in, you can determine when the add-in is loaded. |
| Gives you the ability to create a template for use in any new add-in projects | You can create a template for Visual Basic 6.0 or Visual C++ to reuse every time you create a COM add-in. |
| Provides in each application a consistent add-ins dialog box that displays a list of available add-ins | You can access the add-ins dialog box by clicking the Add-Ins menu item or a related item on the Tools menu in each application. In Office 2000 you can access the COM Add-Ins dialog box from the COM Add-Ins command. |
Although it'll take a little time to transfer your skills to the new COM add-in model, once you learn it you'll know how to create an add-in for any Office application. If you're an expert in developing add-ins for one Office application and you had plans on developing an add-in for another, you won't need to learn any details about connecting add-ins to another Office application when you use the COM add-in model.