Early Binding vs. Late Binding
To automate Outlook, you must first have access to Outlook's object model. That is, to manipulate Outlook's objects, you must first be able to "see" them. There are generally two ways to expose an object model to your Excel application, known as early binding and late binding.
"Binding" means exposing the client object model to the host application. In our case, that means exposing the Outlook object model to our application in VBA for Excel. Outlook's object model is stored in an OLB (Object Library) file. Binding the OLB to your Excel application is what exposes the object model.
Manually binding the OLB file is called early binding. It's "early" because you are exposing the object model during design-time, as opposed to during run-time. You do this via the Tools menu in the VBE, specifically, Tools – References. The references dialog is shown with a list of files with which to bind. It's likely that the list is quite long and much of it you will never use.
Below is an example of the references dialog window with a reference set to the Outlook Object Library:
Since I'm using Outlook 2000, the name of the library is Microsoft Outlook 9.0 Object Library. The 9.0 portion of the name will be different if you are using a different version of Outlook. Incidentally, the name of the OLB file that houses this library is msoutl9.olb. You can see the path where it is stored in the lower section of the dialog.
Selecting a reference in this dialog does absolutely nothing. You MUST select the check box next to the name in order to set the reference. Many times I have simply selected the reference and closed the dialog only to encounter the Compile Error: User Defined Type not Defined. When you get this error, the first thing you should check is that you have set the reference correctly.
Once you've gone through the above process, you have a properly set reference and have successfully exposed Outlook's objects to your application. To use those objects in your code, you can create a procedure like this:
Late binding has the same effect as early binding. The difference is that you bind the object library in code at run-time. You don't use Tools-References as with early binding, but rather you use the GetObject or CreateObject functions. The code below does the same thing as CheckBinding above, but uses late binding.
You use CreateObject when you want to create a new instance of Outlook and GetObject if you want to reference an already running instance of Outlook. For most of the examples on this page, CreateObject will do just fine. To send an e-mail, create a task, or various other activities, it doesn't matter if you use an existing instance or a new one - the same information exists in both. You would use GetObject if you wanted to display something in Outlook, for instance, a calendar. In that case, you wouldn't want two Outlooks running just to display the calendar, you would want to use an existing instance if there is one, and create an instance if there isn't. The following code uses late binding to display the default calendar folder of the existing instance of Outlook and creates an instance if there isn't an existing one.
Dim olApp As Object
The declarations section uses the Object data type. With early binding, we used Outlook.Application to Dim the variable "olApp." But without a reference set, VBA won't know what Outlook.Application means because we haven't exposed the object model. Therefore, any objects that we will use from the Outlook object model, must be declared with the generic Object data type.
On Error Resume Next
The GetObject function will raise an error if there is no existing instance of Outlook, so we used On Error Resume Next to ignore that error. Then we tested for the specific error, and if the error was raised, we used CreateObject. We reset error handling with On Error GoTo 0 so that we don't disguise any errors later in the procedure.
Both early and late binding have advantages and disadvantages. Late binding is slower than early binding because the binding takes place during run time. When you do the work in design time, the code will run faster. When you are writing the code using late binding, you lose some conveniences. Specifically, you won't see the Intellisense showing you the properties and methods of the objects as you type them. Also, the object browser (F2) won't show any of Outlook's objects. Finally, you don't get the advantage of using built-in constants when using late binding. From the code above
would look like this in code that was early bound
olFolderCalendar is a built in constant within the Outlook object model that won't be exposed if you haven't set a reference. Built-in constants can make the code much more readable and easier to debug.
All that seems to make a pretty good case for early binding, but late binding has one very big advantage that can't be overlooked. When you late bind, it doesn't matter which version of Outlook the user has installed. VBA will use the class name supplied with GetObject or CreateObect ("Outlook.Application" in our case) and find the correct object model to reference. In the early binding discussion above, you'll note that I set a reference to Microsoft Outlook 9.0 Object Library because I'm using Outlook 2000. If I were to send a procedure to someone else who was using an earlier version of Outlook, the code would fail because they wouldn't have that specific object library installed. For later versions of an object model, VBA should automatically upgrade the reference. I say "should" because I don't trust it, although I don't have any evidence to support that mistrust.
To get the most out of the VBA development environment and still write robust code, you should write the code early bound, but change it to late bound before distributing it. Even if you write it for personal use only, it makes sense to convert it to late bound. Someday you will have a different computer or send it to your brother and it won't work because they will have an earlier version. If you're a die-hard procrastinator like me, you will be cursing yourself for not converting to late bound sooner.