Why I prefer late bound code
March 6, 2009 • JP • No Comments • Rate This Article
• Links to this article
A recent discussion on the Excel-L mailing list had me thinking about late bound versus early bound, and why I prefer late bound VBA code. Someone posted some code there to solve someone else's problem and mentioned that you had to set a reference to a certain object library before running the code. I suggested a late bound version that would also work, without setting a reference.
So I feel the need to explain why I like late bound code.
To me it seems less professional if you have to set library references in order for a macro or application to work. I say that in the knowledge that some of the code on this site is early bound 
I'm planning on rectifying that soon.
I like the flexibility of late bound code; it can just be dropped into a module and run without regard for the version of the program you are automating. You don't have to remember to set references, or remember to remind others to do so, so you can send the code to anyone and it will work properly every time (well, more often than early bound when you forget to set a reference). You also don't have to worry about someone setting references to the wrong version of an object library, because in some cases you can specify the object model version in your late bound calls.
What I do is first write the code early bound, then convert the object to Object type before distributing it. See Take advantage of Intellisense when writing late bound code for details on doing so.
Of course, I recognize the main reason for using early bound; the code, in many circumstances, runs faster. If version concerns are unlikely, or if you're only using the code for yourself, I encourage early binding. But for all other cases, late binding is better. Your macro or application will be as robust as an early bound equivalent, and more portable.
I'd be curious to hear how others handle binding. Do you have a particular opinion either way?
VBA ·
Rate This Article:
(1 votes, average: 5.00 out of 5)
Loading ...What now?
Subscribe To The Blog
Email This Article
Follow Me On Twitter
My Facebook Page
Or just keep reading:
I'm just an average guy who writes VBA code for a living. This is my personal blog. Excel and Outlook are my thing, with a sprinkle of Access and Word here and there. Follow this space if you want to learn more about VBA. Keep Reading »
Previous Post: Weather formula
Next Post: More Twittering in Excel News
Almost everything I distribute is late-bound. There are too many versions of Office floating around to rely on a particular one being present, although one could early-bind to Office 2000 and newer versions would adapt.
One major problem occurs when people share workbooks with early-bound code. If the workbook is bound to Office 2000, and they use Office 2003, the workbook is updated to 2003. Then someone who tries using the code in 2002 may encounter errors ('library not found').
Make sure you test all your code in the earliest version it will be used in (e.g. Office 2000 SR-2), to make sure that you don't use VBA objects which were added in the later versions, or that at least you handle the errors that may arise.
One more point, regarding the improvement in code execution speed from using early binding:
If most of the time running the application is consumed by the user scratching his chin thinking of what to do next, saving a few milliseconds in code execution is meaningless.
Yet another reason not to use it — early bound references downshifting to earlier versions! I had forgotten about that.