PRB: Office 97 Automation Client Fails After Re-compilation with Office 2000 or Later Type Library (242375)
The information in this article applies to:
- Microsoft Office Access 2003
- Microsoft Access 2002
- Microsoft Access 2000
- Microsoft Access 97
- Microsoft Office Excel 2003
- Microsoft Excel 2002
- Microsoft Excel 2000
- Microsoft Excel 97 for Windows
- Microsoft Office Word 2003
- Microsoft Word 2002
- Microsoft Word 2000
- Microsoft Word 97 for Windows
- Microsoft Office PowerPoint 2003
- Microsoft PowerPoint 2002
- Microsoft PowerPoint 2000
- Microsoft PowerPoint 97 for Windows
- Microsoft Visual Basic Professional Edition for Windows 5.0
- Microsoft Visual Basic Professional Edition for Windows 6.0
- Microsoft Visual Basic Enterprise Edition for Windows 5.0
- Microsoft Visual Basic Enterprise Edition for Windows 6.0
- Microsoft Visual C++, 32-bit Professional Edition 5.0
- Microsoft Visual C++, 32-bit Professional Edition 6.0
- Microsoft Visual J++ 6.0
This article was previously published under Q242375 SYMPTOMS An Automation client that successfully automated an Office
97 application crashes with the same Office 97 application after the program is
recompiled using an Office 2000 or later type library. You might receive an
error similar to one of the following: The instruction
at 0x00000000 referenced memory at address 0x00000000. The memory could not be
read. -or- Run-time error '-2147417851
(80010105)': Automation error CAUSE The Office 2000 or later application has a new member that
functionally replaces an Office 97 member with the same name (which is still in
the newer Office application, but is hidden.) If your automation controller
uses early binding and, more specifically, vtable binding, then the entry in
the vtable points to the binary implementation of the revised method. Because
the new implementation is not in the Office 97 application, the call fails.
RESOLUTION To work around this problem:
- Use late binding instead of early binding.
-or-
- Bind to the type library for the earliest version of the
Office application you are automating.
Late binding is recommended for automating multiple versions of
a Office application from an out-of-process client. The original implementation
of the revised member is also in the newer Office version and is located in the
same position relative to the beginning of the interface. Thus, an Automation
client compiled with the Office 97 type library works with the Office 2000 or
later application. Note for Access Automation Clients If you are developing an Automation client for both Microsoft
Access 97 and 2000, you should not use early binding: late binding is recommended. The Access 2000
object model was modified such that it breaks both binary (vtable) and dispid
compatibility. Any client application that uses early or dispid binding to
Access 97 might fail to work properly when run against Access 2000.
See the "References" section below for more information. STATUS This behavior is by design. REFERENCES
For additional information about binding in Visual
Basic, click the following article number to view the article in the Microsoft Knowledge Base:
245115
INFO: Using Early Binding and Late Binding in Automation
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 informationabout developing an Automation client for multiple versions of a Microsoft Office application, click the following article number to view the article in the Microsoft Knowledge Base:
247579
INFO: Use DISPID Binding to Automate Office Applications Whenever Possible
Modification Type: | Major | Last Reviewed: | 3/23/2006 |
---|
Keywords: | kbAutomation kbprb KB242375 kbAudDeveloper |
---|
|