This article was previously published under Q165273
This article has been archived. It is offered "as is" and will no longer be updated.
OLE Automation code that successfully controlled previous versions ofMicrosoft Excel may fail with Microsoft Excel 97. If the code wasgenerated by a scripting language, you may get an error message similar tothe following:
Method does not exist
This problem can be caused by an improperly implemented OLE AutomationController. An OLE Automation Controller actually makes the calls to aserver application's IDispatch interface to allow that server to becontrolled by the client.
In this case, the problem relates to how the IDispatch::Invoke method iscalled. The Invoke method requires that you specify the context of theIDispatch call by passing one or more of the following flags via thewFlags parameter:
These flags indicate whether the function being called via IDispatch shouldbe called as a property or a method.
Previous versions of Microsoft Excel implemented their collection accessorfunctions as methods. For example, consider the following line of VisualBasic For Applications, Excel edition code:
Workbooks(1).Worksheets(1).Range("A1").Value = 10
Workbooks, Worksheets, and Range are implemented as methods in MicrosoftExcel version 5.0 and 7.0. However, Microsoft Excel 97 implements thesesame calls as properties.
If OLE Automation Controllers break when they try to drive Excel 97, it is usually because they are passing DISPATCH_METHOD as thewFlags parameter of IDispatch::Invoke. Because these functions are nolonger implemented as methods in Microsoft Excel 97, the Invoke methodfailS with DISP_E_MEMBERNOTFOUND. If you are using a scriptinglanguage on top of the controller, you generally get an error messagesimilar to the one mentioned above.
To resolve this problem, modify the OLE Automation Controller code so thatcalls to IDispatch::Invoke include DISPATCH_PROPERTYGET as part of thewFlags parameter. Though you can pass DISPATCH_PROPERTYGET by itself wherethese property calls are being made, the best solution is to logically ORthis flag with DISPATCH_METHOD (DISPATCH_PROPERTYGET | DISPATCH_METHOD).By doing this, you ensure that the function call succeedsregardless of whether it has been implemented as a property or a method.
It should be emphasized that this problem is not a problem in MicrosoftExcel. The problem lies in the implementation of the OLE AutomationController. The only solution to this problem is to fix the OLE AutomationController code.
Customers who did not write the OLE Automation Controller (such as thosewho may be using a scripting language) should contact their vendor forsupport.
To confirm that this is a problem in the controller code, Visual Basicshould be used to automate Microsoft Excel in the fashion attempted by thenon-functioning controller. If the Visual Basic test is successful, theproblem lies in the controller.
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
Developers who have used the Class Wizard in Visual C++ togenerate wrapper classes to automate Microsoft Excel may also encounterthis problem if they generated the classes from an older type library.Class Wizard reads the type library and calls IDispatch::Invoke withwhichever flag is appropriate. When used with an older type library, itsees that the collection accessors are implemented as methods, so ituses the DISPATCH_METHOD flag when it calls these functions. Thesolution is the same. Logically OR DISPATCH_METHOD withDISPATCH_PROPERTYGET for the wFlags parameter in the Dispatch helperfunction calls. This results in IDispatch::Invoke being properlycalled by the wrapper classes.
For additional information, please see the following: