INFO: Use DISPID Binding to Automate Office Applications Whenever Possible
This article was previously published under Q247579
This article has been archived. It is offered "as is" and will no longer be updated.
When you are automating any Office application from Microsoft Visual Basic or Microsoft Visual C++ and you expect to communicate with more than one version of the application, Microsoft recommends that you use late binding with cached DISPIDs (DISPID binding), or late binding in general, to remain compatible across current and future versions of the application.
The two most commonly automated Office applications, Microsoft Word and Microsoft Excel, are distinct in that their implementations of IDispatch (late binding) predate the v-table methods that are used by early bound clients. These implementations of IDispatch have been highly optimized and run slightly faster than early binding if using a cached DISPID. For this reason, DISPID binding to these two Office applications is recommended for out-of-process clients. As new functionality and requirements are added to the product, Office applications will extend the interfaces that are used for Automation in order to add new properties, methods, and events to their object models. In rare cases, these changes may cause unpredictable behavior or application errors when early binding is used because the v-table may change between versions. For this reason, Microsoft recommends the use of DISPID binding to Office if the client needs assurance of compatibility across versions.
If a client cannot perform DISPID binding, early binding offers the second fastest method of calling Word and Excel objects out-of-process, but for the reasons stated previously, is not guaranteed to be completely compatible between versions. Clients who want to use early binding should bind to the oldest version of the Office application to which they want to be compatible.
Developers who use early binding should be aware that if they recompile their project in Visual Basic, it is possible that their project will automatically upgrade their reference to a new version of the type library, causing that project to work only with that version of Office and later. For example, if a project that contains a reference to the Word 8.0 Object Library (Word 97) is recompiled on a computer with Word 2000, the reference may be automatically changed to the Word 9.0 Object Library, causing the project to work only with Word 2000 and later. For additional information about this issue, click the following article number to view the article in the Microsoft Knowledge Base:
242375 PRB: Office 97 Automation Client Fails After Re-compilation with Office 2000 or Later Type LibraryDevelopers who use Microsoft Access need to know that Access 2000 is not binary compatible with Access 97. If you need to work with both versions of the application, you must use late binding.For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
246237 BUG: Access 2000 Object Model Breaks Binary Compatibility
For additional information about the types of binding that you can use and what the types mean, click the following article numbers to view the articles in the Microsoft Knowledge Base:
245115 INFO: Using Early Binding and Late Binding in Automation
244167 INFO: Writing Automation Clients for Multiple Office Versions
Article ID: 247579 - Last Review: 12/05/2015 17:43:52 - Revision: 5.2
Microsoft Office XP Developer Edition, Microsoft Office 2000 Developer Edition, Microsoft Office 97 Developer Edition
- kbnosurvey kbarchive kbautomation kbinfo kbprogramming KB247579