A brief explanation of early & late binding
Some of the examples on this site require early binding, but most use late binding.
Early binding means you are referencing object libraries at compile time, rather than run-time. Late binding means you are declaring your objects As Object or As Variant.
The "Theory"
Two steps are required to declare early bound objects:
- Set a reference to the object library by going to Tools » References in the VBA Editor, and
- Declare objects as their intended type instead of As Object or As Variant.
If you set references to object libraries and typecast your objects accordingly, you will have access to the properties and methods of that program during the code-writing phase, which is an immense benefit for anyone, even experienced programmers.
It makes writing code much easier because you can use the Intellisense feature to auto-complete code, which avoids many syntax errors and cuts down on time spent coding. It makes your code faster, since VBA doesn't have to waste time at run-time figuring out if your method calls are valid for any given object.
The "Practice"
To set a reference to an object library, open your favorite Office program and press Alt-F11 to access the VB Editor, then Click Tools » References and select the appropriate library.
For Excel, choose "Microsoft Excel x.0 Object Library", or for Outlook choose "Microsoft Outlook x.0 Object Library".
The "x" stands for your version; Office 2000 is version 9, Office XP, version 10, Office 2003 is version 11, and Office 2007 is version 12. Office 2010 is version 14.
So if you were setting a reference to the Excel 2003 Object library, choose "Microsoft Excel 11.0 Object Library." This assumes that it is installed on the local computer.
The benefits of late binding
At this point you might be asking, with all these benefits, why would anyone ever want to use late binding?
Well, there are several reasons.
- The code isn't really that much slower.
- You don't need to worry about different versions being on whatever computer the code is running on.
- You don't need to worry about adding object references through the Tools » References interface.
If I write:
Dim objOL As Object Set objOL = CreateObject("Outlook.Application")
On your computer that could mean Outlook 2000, on mine, Outlook 2003, on someone else's, Outlook 2010.
The benefit is seen when writing code for others: your co-workers, friends and others can use the code directly without having to set early bound references.
But just because you give out late bound code, does not mean you have to write late bound code.
What I do now is add the object library reference, code my application early bound, then convert everything to late bound code before using it in a "real" application (or posting it on my blog). See Why I prefer late bound code and Take advantage of Intellisense when writing late bound code for details on just how to do that. That way I get the benefits of early bound AND late bound code.
Don't get tripped up by late bound references
You should make a habit of fully qualifying all of your object references.
For example, instead of Dim Rng As Range use Dim Rng As Excel.Range to make sure the object model you are working with knows for sure what library you are using (since both Word and Excel have a Range object). This is especially prudent for late bound code because no Intellisense can tell you that you are writing the wrong code.
The only time I recommend you not set explicit references (thereby using early binding) is when you don't know what type of object you are working with.
For example, when you are cycling through your Outlook Inbox and processing mail items, you might run into a meeting request.
If you wrote Dim item As Outlook.MailItem instead of Dim item As Object, your code would fail when it tries to treat the meeting request like a message. If you declare the object reference as a generic Object, you can always check each one in an IF statement such as:
For Each item In objFolder.Items
If TypeName(item) = "MailItem" Then
' do processing on messages only here
End If
Next item
That way you are covered no matter what type of item you reference.
Example
Here is an example to illustrate the difference when coding. Early bound object reference:
Dim objOL As Outlook.Application Set objOL = CreateObject("Outlook.Application")
Late-bound object reference:
Dim objOL As Object Set objOL = CreateObject("Outlook.Application")
It doesn't matter how you actually instantiate the object, it's the declaration that counts. So you can use CreateObject (and GetObject) with an object declared as Outlook.Application. I do it this way so I can switch between early and late bound, I only have to change one line (the declaration).
Following best practice, all declarations are placed together at the beginning of each procedure. The code to declare an object and instantiate it are not always found together. So the changes (if any) all take place in one section of code, making it even easier to switch between early and late binding.
Takeaways
- If you declare an object As Object, it will always be late-bound no matter how you create it.
- It is not the instantiation that determines binding, it is the declaration.
- To declare an object as early bound, you must set an object reference using Tools » References and then declaring natively-typed objects.
- Write your code early bound, then convert to late bound to take advantage of both systems.
