Late vs. Early Binding

[mike777]

Hello and thanks for reading my question.
We have a mixture of Office 2000, Office XP and Office 2003 clients.
I just created an application that uses early-binding to send out e-mails via MS Outlook.
The entire application fails when it is run on a machine that has a different version of MS Office, since the folder structure is different and the olb file names are different(c:\program files\microsoft office\office\msoutl9.olb vs. c:\program files\microsoft office\office11\msoutl.olb, etc.). This causes a Reference in the VB Design Environment (Tools > References) to be invalid and preceded by "MISSING:".
On the client machine where the app fails, I deselect the Reference to "Microsoft Outlook 9.0 object library... " and the app works (even though the MS Outlook Reference was the reference with the lowest priority).
So in the source code, I changed everything related to Outlook to late binding and it works fine on all machines now.
Is there a better way to deal with this issue? I know that late binding is slower, so I'd like to use the early binding if possible.
Thank you for your help.
-Mike Kemp

 

[strongm]

>I know that late binding is slower

So accepted wisdom would suggest. However it is actually generally not as slow as you might think on modern hardware (i.e. frankly you just won't notice it), and the performance hit (such as it is) mostly occurs at instantiation of an object

 

[Sheco]

The following is pure speculation but...

Would it work if you put both libraries on your development box and put references to both of them, do On Error Resume Next, attempt to create the object with the more common library, then if Err.Number <> 0 do Err.Clear and attempt to create them with the other library.

I have no idea if that would work but it might.

/shrug

 

[mike777]

strongm,
So, you're saying that you could just use late binding all the time without ill-effect? if this is the case, it would solve all of our software version issues (we have these issues in other areas as well). thanks.

sheco,
the thing is, in this case, when there was that missing Reference, it was causing other things to mess up. specifically, i was getting something like "function not found" on a line of code that had the UCASE function, and the UCASE function was what was highlighted. like i said, this Outlook reference was the last in the list priority-wise, so i was surprised to see the compiler get hung up on the UCASE function. then when i deselected the missing Reference, everything worked (although I'm sure my code that automates Outlook would not work).
thanks.

 

[strongm]

>without ill-effect?

You lose a number of things in the IDE, such as autocompletion, predeclared constants, etc.

 

[HughLerwill]

Strongm,

It seems to be generally recommended that 1) you use the Reference to the Office object and early binding or 2) use no reference and late binding, in the latter case you have to give up constants defined in the object library and other convieniences, 'things in the IDE'.

I find that I can use a ref to Excel 10.0 Object library and late binding successfully and maintain compatibility right down to Excel 95. Obviously I have to avoid any features not present in Excel 95 in the code and have an old 95 box for testing. Thus I seem to have have compatibility AND the 'things in the IDE'.

Is this odd?

regards Hugh

 

[strongm]

Oh, there are a number of ways to keep the IDE features (as you have discovered).