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


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.

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 or later, and now has more arguments than the Word 97 Add method did. Early binding to the vtable member finds the new member in Word 2000 or later. 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 or later type library.

    -or-

  • 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 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