Microsoft Office 2000/Visual Basic Programmer's Guide |
Before one application can work with the objects exposed by another application's type library, it must first determine what information is contained in that type library. The process of querying the objects, methods, and properties exposed by another application is called binding. VBA programming in Office applications supports two kinds of binding: early binding and late binding. How and when binding occurs can have a great impact on how your solution performs.
If you establish a reference to the application's or component's type library, you can use early binding. When early binding is used, VBA retrieves information at design time about the application's objects directly from the type library, thus allowing you to declare object variables as specific types. For example, if you establish a reference to the Microsoft Word 9.0 object library when you are working with Word documents, you can declare object variables by using data types that are specific to Word, such as the Documents or Document types. Early binding reduces the amount of communication that needs to occur when your solution is running, thereby enhancing your solution's performance.
Late binding queries the application you are automating at run time, which allows you to declare object variables by using the generic Object or Variant data type. In general, late binding is useful if you are writing generic code to run against any of several applications and won't know the type of object you are working with until run time. Note that the additional overhead of querying an application at run time can slow down the performance of your solution.
Note Some applications and components that support Automation support only late binding. All Office 2000 applications and most contemporary applications that support Automation support both early and late binding. However, scripting languages such as VBScript and JavaScript don't support early binding because they don't support references or specific object data types (for example, in VBScript only the Variant data type is supported).
Early binding allows you to declare an object variable as a programmatic identifier, or class name, rather than as an Object or a Variant data type. The programmatic identifier of an application is stored in the Windows registry as a subkey below the \HKEY_CLASSES_ROOT subtree. For example, the programmatic identifier for Access is "Access.Application"; for Excel it is "Excel.Application."
When you are using early binding, you can initialize the object variable by using the CreateObject or GetObject function or by using the New keyword if the application supports it. All Office 2000 applications can be initialized by using the New keyword. Because the Outlook 2000 programming environment for Outlook items supports only scripting, you can't use early binding declarations of any sort in its VBScript programming environment; however, you can use early binding in VBA code in a local Outlook VBA project or COM add-in, or in Automation code that works with Outlook from another host application.
Early binding is the friendly name for what C programmers call virtual function table binding, or vtable binding. In order to use early binding, the host application must establish a reference to a type library (.tlb) or an object library (.olb), or an .exe, .dll, or .ocx file that contains type information about the objects, methods, properties, and events of the application or service you want to automate.
In the following code fragment, an Application variable is declared by using the programmatic identifier for Word (Word.Application) and a new instance of Word is created by using the Set statement with the New keyword:
Dim wdApp As Word.Application
Set wdApp = New Word.Application
If the code following these lines doesn't set the Application object's Visible property to True, the new instance of Word will be hidden. All Office applications are hidden by default when they are automated from another application.
Use early binding whenever possible. Early binding has the following advantages:
Syntax checking When you use early binding, VBA checks the syntax of your statements against the syntax stored in the object library during compilation rather than checking it at run time, so that you can catch and address errors at design time. For example, VBA can determine if you are using valid properties or methods of an object, and if you are passing valid arguments to those properties and methods.
Support for statement-building tools When you use early binding, the Visual Basic Editor supports features that make writing code much easier and less prone to errors, such as automatic listing of an object's properties and methods, and pop-up tips for named arguments.
Support for built-in constants When you use early binding, your code can refer to the built-in constants for method arguments and property settings because this information is available from the type library at design time. If you use late binding, you must define these constants in your code by looking up the values in the application's documentation.
Better performance Performance is significantly faster with early binding than with late binding.
Late binding allows you to declare a variable as an Object or a Variant data type. The variable is initialized by calling the GetObject or CreateObject function and specifying the application's programmatic identifier. For example, in the following code fragment, an Object variable is declared and then set to an instance of Access by using the CreateObject function:
Dim objApp As Object
Set objApp = CreateObject("Access.Application")
Late binding is the friendly name for what C programmers used to call IDispatch binding, and was the first method of binding implemented in applications that can control other applications through Automation. For this reason, you can use late binding to maintain backward compatibility with older applications. However, late binding uses a lot of overhead; it is faster than dynamic data exchange (DDE), but slower than early binding.
Tip DDE is a protocol that was established before OLE for exchanging data between Windows applications. There is no need to use DDE to exchange data between Office applications because of their support for Automation. However, you may have to use DDE from some other application that doesn't support Automation code in order to work with data from an Office application. For more information about using DDE, search the Visual Basic Reference Help for the Office application you want to work with.
The CreateObject function must also be used to work with objects from any Automation component from script. This is because scripting has no method of establishing references to type libraries to support early binding.