PRB: Office 97 Automation Client Fails After Re-compilation with Office 2000 Type Library

ID: Q242375

The information in this article applies to:

Microsoft Office 2000
Microsoft Office 97 for Windows
Microsoft Visual Basic Professional and Enterprise Editions for Windows, versions 5.0, 6.0
Microsoft Visual C++, 32-bit Professional Edition, versions 5.0, 6.0
Microsoft Visual J++, version 6.0

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 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 application has a new member that functionally replaces an Office 97 member with the same name (which is still in the Office 2000 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.

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 Microsoft Office application from an out-of-process client. The original implementation of the revised member is also in the Office 2000 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 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.

MORE INFORMATION

Early-bound code, such as the following, which you might find in an Automation client for Microsoft Word, illustrates the problem:


Dim oWord as New Word.Application
oWord.Documents.Add

The Add method of the Documents object is enhanced for Word 2000 and now has more arguments than did the Word 97 Add method. Early binding to the vtable member finds the new member in Word 2000. Because the vtable pointer does not find that member with Word 97, the Add method fails.

To correct the problem, you can either:

bind to the Word 97 type library instead of the Word 2000 type library.

modify your code to use late binding using the following code:


Dim oWord as Object
Set oWord = CreateObject("Word.Application")
oWord.Documents.Add

REFERENCES

For more information about binding in Visual Basic, please see the following article in the Microsoft Knowledge Base:

Q245115 INFO: Using Early Binding and Late Binding in Automation

For more information, please see the following article in the Microsoft Knowledge Base:

Q246237 BUG: Access 2000 Object Model Breaks Binary Compatibility

Additional query words: crash automate excel word access powerpoint -2147417851 80010105

Keywords : kbAccess kbAutomation kbExcel kbPowerPt kbWord kbGrpDSO kbDSupport
Version : WINDOWS:2000,5.0,6.0,97; winnt:5.0,6.0
Platform : WINDOWS winnt
Issue type : kbprb