early binding vs late binding
<snip>
Quote:
> I gather that early binding yields
> the best performance, so I would like to use this method.
The question is how much difference in performance?. For example, while c++
is faster then the
VBA in ms-access, you will not in general see any
difference in performance between a ms-access application that uses JET and
one that is written in c++.
Early biding does not make the code run faster, but reduces the time taken
to CALL the code. (at the end of the day..this does mean things run slower,
but it is not the code execute speed that changes here).
For example, if you launch word via automaton, or by a double click on the
desktop you are not going to notice any difference. The reason why late
binding runs slower is because the code has to resolve what method, or chunk
of code you are about to call at runtime. That is also why late binding does
not break references, because the reference occurs at run time..and not
compile time (and, thus that is also why you don't get intel-sense).
However, once the reference is resolved, then the code runs the same speed
as early binding. So, lets assume that is reference resolving only takes .01
of a second. If you by automation call 5 routines in the object, then you
use up .05 of a second. Usually, you are not calling thousands of routines
in the automation object. If you do call a method 5000 times, then that .05
becomes 250 seconds.
So, that is why you would NEVER using late binding for your recordsets.
However, to automate word, I can't remember every executing more then 5, or
6 word commands. Even if you execute 30 commands (to merge 30 fields), then
you would only slow down the process by a very small amount (like maybe 1/2
second tops---you users will not notice the difference).
Remember, the word, or Excel, or whatever you are using does not run faster,
but the time taken to RESOLVE WHAT routine to run by automation is why late
binding runs slower. There is no magical speed up in the code. Hence, if you
are not calling a lot of methods over and over, then the performance hit via
late binding is not noticeable at all. I mean, launching word, and waiting
for it to load is the big penalty. The rest is pretty well the same.
Quote:
> question is how do I set references to prior versions of type
> libraries if I currently only have later versions of the libraries on
> my machine.
You can't, and I thought we were going to use late binding anyway.
Quote:
> My second question relates to late binding. If I use late binding, do
> I need to set a reference to the type library at all?
No, you don't need to set any reference. That is why late binding is so much
more reliable, since you don't get broken references.
Quote:
> Last question: If I do use late binding, is it common practice to use
> early binding during development in order to benefit from intellisense
> features and then switch to late binding when development is complete?
Yes, you bet. Sometime you need to change a bit of code. It depends on the
object you are using.
Quote:
> One of the components I automate most frequently is graph. I often
> have problems when running the application on machines with older
> versions of office since they have older versions of the graph type
> library. Again I am not sure how to set a reference to the oldest
> version of the graph type library if it is not on my machine.
Hopefully, the older versions are compatible. You will have to test this. I
never used the graph object. However, you must not use any newer features of
the graph object. You must write your code to only use features in the older
versions. If you write using the most early features, and don't use later
features of the graph, then you should be ok.
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
http://www.attcanada.net/~kallal.msn
