Select the product you need help with

BUG: Word may stop responding or the Automation command may fail when you use a custom application to automate an instance of Word

Article ID: 944139 - View products that this article applies to.

SYMPTOMS

Consider the following scenario. You have a custom application that automates Microsoft Word 2002, Microsoft Office Word 2003, or Microsoft Office Word 2007. In this scenario, Word may stop responding or the Automation command may fail. This problem occurs when the following conditions are true:

The instance of Word that you are automating is already running. The instance was obtained in the Running Object Table (ROT) by using the GetObject API or the GetActiveObject API.
The instance of Word is currently being used by another application for OLE embedding. For example, a Word document is open in Internet Explorer inside the Web browser or a Web frame.
The OLE host application supports the IOleCommandTarget interface. The OLE host application offers its own code for functions that are invoked by a Word menu or toolbar commands.
The client application has called an Automation function. The Automation function invokes a menu or a toolbar command that is handled by the OLE host application instead of by Word.

Note This problem most frequently occurs when the code tries to call the Documents.Open method to open a document in the instance of Word.

Back to the top | Give Feedback

CAUSE

This problem occurs because some commands that are invoked by Automation follow the same code path as menu commands and toolbar commands in Word. If the embedded document is the currently active document when the code makes a call to Word, Word will ask the OLE host application to confirm whether the command should be enabled. Then, Word will call the OLE host application to let it override the function, if it is required. Because of this behavior, the OLE host application may tell Word to disable the command. This causes an unexpected error. Or, it may override the command and display its own UI dialog box or function. This behavior may cause the Automation caller that is trying to invoke the function to stop responding.

For example, with the Documents.Open method, the OLE host application, such as Windows Internet Explorer 7, may override the Open command by using its own function. When your code is called, the OLE host application's Open command is called instead of the Open command in Word. Therefore, the call to Word can accidentally display an Open dialog box that belongs to the OLE host application. The Word document that the code is trying to open will not open.

Back to the top | Give Feedback

WORKAROUND

Automation clients are advised to create a private instance of Word if they have to automate Word without user interaction. Use the New command, the CreateObject command, or the CoCreateInstance command, depending on your programming language. If you have to use the running instance of Word, you can open the document in that instance by creating a file moniker and binding directly to the file moniker. You can do the same thing in higher-level languages. Use the GetObject method with the document name of the file that you want to open instead of the Word application ProgID.

For example, the following code can resolve the problem if you followed the steps in the "Steps to reproduce the problem" section.

Sub TestWordIssueWorkaround()
    Dim oWord As Object
    Dim oDoc As Object
    Set oDoc = GetObject(sPathToTest2Doc)
    Set oWord = oDoc.Application
    oWord.Visible = True
    oDoc.Activate
End Sub

Back to the top | Give Feedback

STATUS

Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the "Applies to" section.

Back to the top | Give Feedback

MORE INFORMATION

OLE command forwarding is a feature of OLE that is used to help better integrate menus and toolbars that are shared by an inplace active object and the host. When Word is embedded in an OLE host application that supports menu and toolbar merging, that host can receive messages from Word when certain built-in commands are invoked by the menu or by the toolbar. It does this through the IOleCommandTarget interface. The commands that may be forwarded during embedding are those listed by the OLECOMDID enumeration. For more information, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn2.microsoft.com/en-us/library/ms691264.aspx

(http://msdn2.microsoft.com/en-us/library/ms691264.aspx)

Some methods in the Word object model that relate to these commands will check with the OLE host application. This behavior occurs if the currently active document is being embedded. In this situation, Word does not recognize that the call was made on behalf of an Automation caller and not on behalf of the user. Word can mistakenly forward the command to the OLE host application. Depending on how the OLE host application handles the command, it may succeed or fail. Additionally, it can cause the OLE host application to run some action on its own before it cancels the Word command. This can have unintended side effects for the application.

If you are working with an instance of Word that appears to be used by OLE, make sure that you open a non-OLE document before you run a command that could be forwarded. Command forwarding is only performed if the active document is inplace active in an embedded situation.

Steps to reproduce the problem

Note The following steps are for Word 2003 and Internet Explorer 7. If you are using Word 2007, you must follow the steps in the following Microsoft Knowledge Base article before you can reproduce the problem by using these steps:

927009

(http://support.microsoft.com/kb/927009/ )

A new window opens when you try to view a 2007 Microsoft Office program document in Windows Internet Explorer 7

Create two new Word documents, and then save them to a local drive as Test1.doc and Test2.doc.
Exit Word after both files are saved.
Start Internet Explorer 7, type the path of Test1.doc in the address bar, and then press ENTER.

Make sure that the document opens in Internet Explorer as an OLE object and not outside the browser.
Start Excel or PowerPoint, and then press ALT+F11 to display the Microsoft Visual Basic for Applications (VBA) development environment.
On the Insert menu, click Module.

In the code window, add the following code.

' Note You must change this string to the path
'       where you saved Test2.doc on your computer.
Const sPathToTest2Doc As String = "D:\Test2.doc"

Sub TestWordIssue()
    Dim oWord As Object
    Set oWord = GetObject(, "Word.Application")
    oWord.Documents.Open sPathToTest2Doc
    oWord.Visible = True
End Sub

Put the cursor inside the TestWordIssue subroutine, and then press F5 to run the code.

The code appears to stop responding. If you switch back to Internet Explorer where the Test1.doc document is open, you see that Internet Explorer has canceled the Open command and displayed its own Open dialog box to the user. When the user closes the dialog box, the VBA code finishes. Notice that Test2.doc is not opened.