Article ID: 247579 - Last Review: December 15, 2003 - Revision: 5.2 INFO: Use DISPID Binding to Automate Office Applications Whenever PossibleThis article was previously published under Q247579 SUMMARY 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. MORE INFORMATION 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
(http://support.microsoft.com/kb/242375/
)
PRB: Office 97 Automation Client Fails After Re-compilation with Office 2000 or Later Type Library
Developers 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
(http://support.microsoft.com/kb/246237/
)
BUG: Access 2000 Object Model Breaks Binary Compatibility
REFERENCES
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
(http://support.microsoft.com/kb/245115/
)
INFO: Using Early Binding and Late Binding in Automation
244167
(http://support.microsoft.com/kb/244167/
)
INFO: Writing Automation Clients for Multiple Office Versions
| Article Translations
|
Back to the top
