Article ID: 319832 - View products that this article applies to.
This article was previously published under Q319832
When you automate a Microsoft Office application, you may receive an error message or you may experience unexpected behavior, as follows.
You may receive one of the following error messages:
Error 91: Object variable or With block variable not set.
Error 462: The remote server machine does not exist or is unavailable.
You may receive one of the following unexpected behaviors:
Error -2147417848 (&H80010108): The object invoked has disconnected from its clients.
This article gives you advice on how to avoid the problem. The article assumes you are familiar with both Office development and the Visual Basic product.
Automation clients may use early binding in Visual Basic (VB) to programmatically work with a Microsoft Office application. When Automation clients do so, they may inadvertently use unqualified property or method calls in their code. This may lead to errors or to unexpected behaviors.
Programmers who use an Office application type library in their VB project must be sensitive to this issue when they write code.
Unqualified References in Visual BasicVisual Basic is designed to make programming simple and intuitive for programmers of all skill levels. VB introduced the concept of the Global object to make the coding for a particular component easier and more user-friendly. Programmers who use the object can call its properties and methods without the need to explicitly dimension and create a new instance of the object. In other words, the object itself can be called from anywhere in the code. Therefore, it is "global." Programmers do not have to explicitly write code on their own to do this.
NOTE: The Global object is differentiated by setting the appobject attribute on the coclass in the type library of the object. It is typically, but not necessarily, called "Global."For example, consider the LoadPicture method in VB. This method is frequently called without qualification, as follows:
However, if you view the LoadPicture function in the Visual Basic Object Browser, you see that the function is really a method on a Global object. VB keeps this Global object loaded for the life of the program. You do not have to dimension or create the object before calling the method. Nor do you have to qualify the call with the object name. VB handles that the first time that the object is accessed. This simplifies the code. VB programmers can focus more on the task at hand than on the objects that are necessary to complete the task.
NOTE: Developers who are familiar with writing ActiveX components in VB will recognize this behavior as the same behavior that you get if you set the instancing property of a Public class to GlobalMultiUse. In fact, a GlobalMultiUse class is a Global object.When the VB compiler encounters a function or a subroutine that does not appear to belong to the current project, the VB compiler searches the list of Global objects that are referenced in the project. The VB compiler looks for a matching function name and a matching signature among the properties and methods of the object. If the VB compiler finds a match, VB sets the code to call that function or property on the Global object.
When the code is called, VB creates the object if the object has not been created before. VB then sets a reference to that object in a hidden variable. The reference is not released until the project is ended. Projects are typically ended when the application shuts down.
Any unqualified method or property call on that object is invoked on the hidden reference. You do not have access to this hidden variable. You cannot change it or release it from VB code.
Global Objects in Microsoft Office ApplicationsMicrosoft Office is designed to use Global objects in much the same way that VB uses them for its native functions. This makes coding easier for macros written in Microsoft Visual Basic for Applications (VBA). VBA code makes wide use of unqualified property and method calls to keep the code simple and to keep the code understandable for beginners.
For example, the following Microsoft Word VBA code sets some text after the third paragraph in a document:
The code uses two objects, ActiveDocument and Selection. Both objects are native to Word VBA. To access these objects, the code makes unqualified method calls on two property procedures on the Word Global object. (The property procedures use the same name and return the respective object.) The process is equivalent to the following:
Look at the two code samples. You can see why most developers prefer to use unqualified code. Unqualified code is easier to understand and is less trouble to write. Additionally, when unqualified code is used in the native container for which it is designed, it is also completely safe.
The Problems in Using Unqualified Code with OfficeProblems may occur when you reference a Global object that does not live inside your process space. In this situation, many of the assumptions about global objects break down. These assumptions include things such as the following: that there is only one instance; that calls to the object are native to the host; or that calls are kept alive for the length of the host application. When these assumptions break down, buggy behavior may result.
Office applications use Global objects and live out-of-process. Therefore, VB code that uses early binding to automate these applications is especially vulnerable to problems involving unqualified method calls. Note that unqualified method calls only occur if you reference the type library for the Office application in the References dialog box. You typically do this when you use early binding. Code that uses late binding is always qualified. It does not experience these problems if you do not reference the type library.
In itself, unqualified code frequently runs just fine in VB, even when it references out-of-process objects. This makes the problems that you experience harder to deal with, because the code appears to work successfully some of the time. There is, however, one warning sign to look for, as follows:
If the code always appears to work the first time that it is run, and if the errors or the unexpected behaviors occur only during subsequent calls to the same code, an unqualified method call is the cause.This problem occurs because the code creates a new instance of the Office application each time that it runs, but the unqualified code caused VB to set a hidden reference to the old instance. Therefore, subsequent calls on the hidden variable (for an unqualified method) are made to the wrong server.
Some of the errors or unexpected behaviors that you might experience if you make an unqualified call to an Office object are as follow:
Qualifying the Code to Avoid ErrorsThe best guideline is to avoid using any Office object that you do not explicitly call from a parent object that you set in a specific variable. In other words, look for code that uses Office objects without qualifying which Office instance or document that it is supposed to refer to. For example, this code uses an unqualified call to display the count of open workbooks in Microsoft Excel:
When you run the code, it appears to run correctly the first time. However, Excel continues to run, even though you called the Quit method. If you call the code again, the message box now incorrectly displays 0 for the workbook count. Your code may now fail where you would expect it to succeed.
To resolve both problems, you must fully qualify the Workbooks object that you reference for the count, as follows:
Some Office objects and functions are typically unqualified in VBA code. They can cause problems if you use that same code in VB and if you do not add the appropriate qualifications. Here is a list of common objects and functions that are typically unqualified in VBA code.
What to Do If You Experience These ProblemsIf you have an existing project that no longer works because of one of the problems in this article, here are a few things you can do to fix it:
For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/178510/ )PRB: Excel Automation Fails Second Time Code Runs
189618For more information about Office Development in general, visit the following Microsoft Developer Network (MSDN) Web page:
(http://support.microsoft.com/kb/189618/ )PRB: Automation Error Calling Unqualified Method or Property
Article ID: 319832 - Last Review: February 1, 2007 - Revision: 5.3