Microsoft Corporation
Automation is a technology supported by Visual Basic® and the Microsoft® Office 95 applications that enables one application to work with another application's objects. Early binding is a feature of Automation that makes Automation code run more efficiently. As a developer, you can take advantage of early binding while making only minimal changes to your code and build solutions that run faster and are more reliable. This article discusses different types of binding and explains why you should ensure that your code is early-bound to get the most out of Automation.
Binding refers to the way in which Visual Basic® code accesses objects in another application. When you use Automation from one application to work with objects in another application, the application in which you are writing Visual Basic code is the Automation controller. The application whose objects you are working with is the Automation server. When an Automation controller creates an object variable that points to an object supplied by an Automation server, Visual Basic must verify that the object exists and that any properties or methods used with the object are specified correctly. This verification process is known as binding. There are two types of binding with which Visual Basic developers need be concerned: late binding and early binding.
Until the release of Microsoft® Office 95, many applications that supported Automation provided only late binding of Automation objects. Late binding occurs at run time and is much slower than early binding. In late-bound Automation code, Visual Basic must look up an object and its methods and properties each time it executes a line of code that includes that object. To verify that the object and its methods and properties are specified correctly, Visual Basic must check with the operating system and with the application that supplied the object.
You can think of late binding as similar to having to look up a phone number in the phone book each time you want to dial the number. Looking up the number is obviously slower than dialing it from memory, although the end result once the number is dialed is the same. ("Hello, Tod? David here. When do you have time to give me that golf lesson?...")
The following lines of code demonstrate late binding:
Dim objExcel as Object
Set objExcel = CreateObject("Excel.Application")
objExcel.Workbooks.Add
Note that the object variable, objExcel, is declared as the generic type Object. When the object variable is declared, Visual Basic doesn't know what type of object the variable will later be used with, but it must set aside a certain amount of memory for this unknown object. Not until the second line of code does Visual Basic have enough information to determine what type of object is actually necessary.
The second line of code creates a new instance of the Excel.Application object, an Automation object supplied by Microsoft Excel, and assigns it to the object variable. Before it creates a new instance of the Excel.Application object, Visual Basic must check the system registry for information on this object. When the third line of code is executed, Visual Basic must look up the Workbooks collection of the Excel.Application object and then the Add method of the Workbooks collection to verify that the collection and method exist and that they have been used correctly. Each time you use the object variable, Visual Basic performs these time-consuming look-ups, resulting in slower performance.
Early binding is the solution to the problem of slow Automation performance. Early binding occurs at compile time rather than run time, so if your code is saved in a compiled state, binding is complete before the code is even run. To return to the phone number analogy, early binding is similar to "speed dialling"—having a phone number in memory rather than having to look it up each time you wish to dial it.
Early binding eliminates the need for Visual Basic to continually verify object information while using the object. Early binding takes place between the Automation controller application and the type library of the Automation server. All applications that support early binding include a type library, which contains information on the application's objects and their properties and methods.
To take advantage of early binding, you must set a reference to the Automation server's type library. When you set a reference to a type library, you notify Visual Basic that you may be using the objects in that type library. Visual Basic loads the type library into memory, which enables it to recognize these objects and bind them when the code is compiled. If you don't set a reference to an application's type library, you can still write Automation code, but it won't be early-bound.
Once you've set a reference to an application's type library, you can declare object variables as specific types of objects. This step is crucial in ensuring that your code is early-bound. For example, from an Office 95 application, you could run the following early-bound code:
Dim appXL As Excel.Application
Set appXL = CreateObject("Excel.Application")
appXL.Workbooks.Add
Note that in this example, the object variable is declared as type Application rather than type Object. Additionally, the Application object type is qualified by the name of the application that is supplying the object, Microsoft Excel. When this code is compiled, Visual Basic creates the correct type of object and looks up every method or property that the developer might use with that object. Once this initial look-up is complete, Visual Basic doesn't need to look up information on the object again. Each time the object is used in code, the information on its properties and methods is readily available, and the code runs much more quickly.
A caveat on early binding: Setting a reference to an application's type library won't automatically make your code early-bound. You must declare object variables as specific object types in order to take advantage of early binding. In the example shown above, if you were only to declare the object variable as type Object, your code would be late-bound rather than early-bound.
There are some additional benefits of early binding that may make writing Automation code easier. When you set a reference to an application's type library, you can view the objects, properties, and methods in that type library in the Object Browser in the Automation controller application. You can also get help on using those objects from the Object Browser, even though you're in another application.
For early binding to work, both the Automation server and Automation controller must support it. If either application does not support early binding, late binding is used instead.
An application can support early binding as an Automation controller, as an Automation server, or both. For example, an application that provides a type library supports early binding as an Automation server. An application that can set references to other applications' type libraries supports early binding as an Automation controller.
The following table lists the applications that support early binding.
| Supports early binding when used as an Automation controller | Supports early binding when used as an Automation server | |
| 16-bit applications | ||
| Microsoft Access 2.0 | No | No |
| Microsoft Excel 5.0 | Yes | Yes |
| Microsoft Project 4.0 | Yes | Yes |
| Microsoft Visual Basic 3.0 | No | No |
| Microsoft Word 6.0 | No | Yes* |
| 32-bit applications | ||
| Microsoft Access 95 | Yes | Yes |
| Microsoft Data Access Objects 3.0 | Not applicable | Yes |
| Microsoft Excel 95 | Yes | Yes |
| Microsoft PowerPoint® 95 | No | Yes |
| Microsoft Project 95 | Yes | Yes |
| Microsoft Visual Basic 4.0 | Yes | Yes |
| Microsoft Word 95 | No | Yes* |
* The Microsoft Word type library is not available with Microsoft Word. It is available in the Microsoft Access Developer's Toolkit and from online sources.
When you write early-bound code, it's a good idea to qualify object types with the name of the application supplying the object. Several applications have overlapping objects in their object models. For example, many applications have an Application object at the top of their object model. If you omit the qualification, Visual Basic may create the wrong Application object.
You can qualify an Automation object with the name of the object library supplied by the Automation server application, as long as you've set a reference to that object library. To determine the name of an application's object library, open the Object Browser and look in the Libraries/Databases list box.
The following examples show how you might qualify different Automation objects:
Dim dbs As DAO.Database
Dim wkt As Excel.WorkSheet
Dim doc As Word.WordBasic
Dim pst As PPT.Presentation
Dim rpt As Access.Report
Note In the References dialog box, there is a Priority button that determines the order in which Visual Basic looks up the methods and properties in referenced type libraries. If you set the order that Visual Basic uses to search these object libraries, you can determine which application's object will be created when you declare an object variable. In this case, there's no need to qualify objects.
Microsoft Excel and Microsoft Project use a different version of Visual Basic for Applications than do Microsoft Access and Visual Basic 4.0. For this reason, when you're using Microsoft Excel or Microsoft Project as an Automation controller, you may need to use a slightly different syntax to declare an object variable as a specific object type in some cases in order to create early-bound code. For example, the following line of code produces the error "User-defined type not defined" when run from Microsoft Excel:
Dim appAccess As Access.Application ' Causes an error.
To avoid generating this error, you can declare the variable in the following way:
Dim appAccess As Access.[_Application] ' Compiles without error.
For some objects, however, the standard syntax works fine. For example, the following code compiles without an error:
Dim dbs As DAO.Database ' Compiles without error.
However, if you try to declare this variable with the second syntax, you'll get an error:
Dim dbs As DAO.[_Database] ' Causes an error.
The best way to handle this problem is to declare all object variables and then compile the code to determine which ones need a different syntax. If you get a "User-defined type not defined" error, try using the other syntax to declare the object.
You should now understand how early binding can help improve the performance and reliability of Automation code. Automation is a tremendous asset to developers who want to leverage prebuilt components, rather than code all application functionality from scratch. Office 95 provides extensive support for early binding, giving the developer an excellent platform for custom solution development.
See "Your Unofficial Guide to Using Automation with Microsoft Office and Microsoft BackOffice" in the Microsoft Access Developer's Toolkit or the MSDN Library (Technical Articles, Applications), or check out the Visual Basic 4.0 documentation (MSDN Library) or the Microsoft Excel 95 developer reference.