Early vs. Late Binding

Article contributed by Dave Rado

There are two ways to use Automation (or OLE Automation) to programmatically control another application.

Late binding uses CreateObject to create and instance of the application object, which you can then control. For example, to create a new instance of Excel using late binding:

Dim oXL As Object
Set oXL = CreateObject("Excel.Application")

On the other hand, to manipulate an existing instance of Excel (if Excel is already open) you would use GetObject (regardless whether you're using early or late binding):

Dim oXL As Object
Set oXL = GetObject(, "Excel.Application")

To use early binding, you first need to set a reference in your project to the application you want to manipulate. In the VB Editor of any Office application, or in VB itself, you do this by selecting Tools + References, and selecting the application you want from the list (e.g. “Microsoft Excel 8.0 Object Library”).

To create a new instance of Excel using early binding:

Dim oXL As Excel.Application
Set oXL = New Excel.Application

In either case, incidentally, you can first try to get an existing instance of Excel, and if that returns an error, you can create a new instance in your error handler.

Advantages of Early Binding

  1. Your code will run considerably faster, because it can all be compiled up front. With late binding, the code relating to an application you declared as an object has to, in effect, be compiled as it runs.
  2. Because your code can all be compiled up front, debugging is far easier – select Debug + Compile, and the compiler will be able to spot syntax errors which would have been missed had you used late binding.
  3. You have full access in your project to intellisense (type a keyword and a dot to get a popup list of properties and methods supported by that keyword, select one to insert it; type a keyword and press F1 to launch the Help topic on that keyword).
  4. You have full access to the application's object model via the Object Browser and VBA Help.
  5. You have access to the application's built-in constants. For instance, if you are automating Word from Excel, you can use:

    6. Dim objWord As Word.Application
    Set objWord = New Word.Application

    With objWord
        .Visible = True
        .Activate
        .WindowState = wdWindowStateMaximize
        .Documents.Open ("c:\temp\temp.doc")
    End With 

    Furthermore, when you type 

    .WindowState =

    you'll get a pop-up list of the supported constants, and can simply pick “wdWindowStateMaximize” from the list.

    If you used late binding, you would need to use:

        .WindowState = 1

    .. and you would need to know (by looking it up in Word's Object Browser) that the value of the constant “wdWindowStateMaximize” happens to be 1.

All this makes programming using early binding immeasurably easier than using late binding.

Advantages of Late Binding

  1. The main advantage is that code which uses late binding is more certain to be version-independent

    If you set a reference in a Word 97 project to “Microsoft Excel 8.0 Object Library”, then the project will run OK on a machine which has Office 2000 installed. Word 2000 changes the reference on the fly to the “Microsoft Excel 9.0 Object Library”.

    But as they famously say, YMMV. Problems have been found in certain circumstances. For instance, if you run a Word 97 project containing a reference to the Excel 8.0 object library on a machine with Office 2000 installed, it will run OK, but you may get the occasional “cannot open macro storage” error unless you save the project in Word 2000. If you do save it in Word 2000, the reference will change to the Excel 9.0 object library. So if you use early binding and support a mixed environment, it may be safest to create separate Word 97 and Word 2000 versions of your addins, despite the maintenance overhead.

  2. The more references your project contains, the larger the file size and the longer it takes to compile.
  3. Some programming environments don't allow you to create references to another application.

Summary

Personally, as someone who finds programming difficult at the best of times, I would never dream of using late binding – why make life harder for yourself than it has to be? But some programming geniuses prefer to use late binding, because of the peace of mind it gives them regarding version independence – or maybe some of them just enjoy the challenge! <g> But you pays your money and makes your choice ...

To those unfortunate souls using programming environments in which you have to use late binding, all I can say is: Look on the bright side – you could have ended up as an Assembly language programmer ...