Summary:
Automate Excel using Late Binding. One of the modules
here converted to Late Binding.
Late Binding Vs Early Binding:
Early Binding is when you tell the application up front where you are going to get your objects from. In late binding the application only finds out as it creates the objects at runtime.
Early Binding Pros:
Faster execution of code (the application uses it's preruntime knowledge of the objects to speed up method and proerty calls)
NB - I have read a little that this applies to inprocess calls (to DLLs like ADO and DAO) but execution is slower for out of process calls (calls to EXEs like Excel, Word etc).
Intellisense.
Object model available for viewing in Object Browser.
Integer parameters for the methods and properties are conveniently titled as constants.
Many code errors are picked up at compiletime.
There is no late binding in .NET if you plan to port your skills.
Dynamic help.
Early Binding Cons:
DLL Hell - this is the biggie - this is where the application was informed that it would be using a version of objects that is not avaialble on the client machine. This may be because they are not installed (in which case there can be no binding, early or late) or they are of an earlier version than the application expected. NOTE - it should not be a problem if the client has a later version of the objects. A simple example is if you develop an application that references the 11.0 (2003) Excel library and distribute to clients running XP - the application will crash. Remember though that the converse (XP Ap, 2003 clients) is fine.
Difficult to have confidence in your application if you cannot be sure about your client's workstation set ups.
Different syntax to what some (e.g. ASP developers) developers might be used to.
Run the master copy of your app on a workstation with a later version of your references and Access will upgrade them for you without warning.
Late Binding (pos and Cons):
Generally the opposite of Early Binding.
The only other pro is that the syntax more closely resembles vbscript (as used in ASP).
EDIT - 2006_08_07 - added note re writing Late Bound code.
If you look at the Pros of Early Binding you will notice that many of the advantages are when you are
writing code. As such it is a good idea to write your full procedure Early Bound to make use of intellisense, picking up compile time errors, the object browser, help and debugging constants and then convert your (working) code to Late Bound. If you review the LateBinding.zip file you will see that I have commented all the sections that I changed and retained the Early Bound code as comments. As a side note, I would recommend the same principle for when you start writing vbScript (just be aware that there are
some further syntax changes beyond the late bound changes).
NB. This is why writing this sort of stuff is so valuable! I might have read a book on COM and numerous articles over the years but I still learned something new researching this post. Relevent links below:
http://word.mvps.org/FAQs/InterDev/E...ateBinding.htm
http://blogs.msdn.com/cambecc/archiv...01/145309.aspx
http://support.microsoft.com/kb/245115/
http://www.codecomments.com/archive2...-6-523102.html
http://support.microsoft.com/kb/247579/EN-US/
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
EDIT - 2006_08_06 - Decided to test the idea that late binding to Excel is quicker than early binding (LateBindingVsEarlyBinding_V1.zip). Rather frustratingly the factor that seems to have the most affect is the order that you call the early binding and late binding procedures. However, the late binding method
does seem to be faster.
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
EDIT - 2006_08_06 - inspired by another of RoyVidar's links I started looking at the difference of New and CreateObject. Must admit I initially thought they were the same. They are not. This is not strictly an Early\ Late Binding issue (simply that you don't get the choice in Late Binding) but I thought it interesting:
MS info on CreateObject Vs New - Link supplied by Roy (Must confess - I am going to have a fresh look at an error that has blighted about 0.5% of the client machines in our organisation armed with this info)
An FAQ page from VB2TheMax (love that name - unashamably geeky)
CreateObject Vs New from ITToolbox
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
EDIT - 2006_08_07 - Some more comments from Roy - here is a nice link for those of you that are getting a little Bamboozled by the tech heavy links above:
Early & Late Binding
I added a note towards the top on recommended technique to write Late Binding code (again thanks Roy).
I am also adding an internationalisation change to the SQL in LateBindingVsEarlyBinding_Vx.zip (guess who's to thank?).
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------
EDIT - 2006_08_07 - Added LateBindingVsEarlyBinding_V2.zip. This tests DAO (an inprocess DLL) for late and early binding speed. Again, the order the tests are run is the main difference and can make either of the methods run faster. I think I need to rethink my testing procedure....
--------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------