Backward compatibility for VB6 COM Excel Add-In

[Nick Hebb]

I posted this in
http://groups-beta.google.com/group/microsoft.public.excel.programming?hl=en
to no avail, so hopefully I'll have better luck here...


I'm developing a VB6 COM Add-in for Excel on a machine that current has
Office XP installed, which means that my VB6 project sets a reference
to the Excel 10.0 (2002/XP) object library.

I would like my add-in to be backward compatible with Excel 2000, which
uses the Excel 9.0 (2000) object library. In order to ensure this, as
far as I can tell I have 3 options:

1. Check the Object libraries for 2000 and XP looking for any
differences that might effect my code. Then cross my fingers and hope
for the best.

2. Buy and install Excel 2000 in order to get access to the older
library.

3. Obtain a copy of the Office 2000 SDK. Unfortunately, I can't seem
to locate this anywhere on MSDN.

Option 1 looks like my best bet. Has anyone tried this with success?
Any gotchas to watch out for.

Option 2 isn't appealing because of the cost and the configuration
headaches. If I had VPC or VMWare it would be less of an issue, but I
don't have either.

Option 3 would be optimal, but I don't know where to obtain a copy of
this SDK. Does anyone know if there are still copies available for
download?

Any advice would be greatly appreciated.

Thanks,

Nick

[Tom Winter]

You will either need to purchase Excel 2000 or use late binding (Dim
oWorksheet as Object). If you use early binding (Dim oWorksheet as
Excel.Worksheet) while referencing Excel 2002, you MAY run into problems on
an Excel 2000 only system. I can give you a good example from Word (my area
of expertise).

The Application.Documents.Open method has changed with each version of Word
(new parameters added). Since the rules of COM say you can't change a
method, Word really adds new methods, and then renames and hides the old
ones. (Use OleView to view Word 2003's type library and you'll see OpenOld,
Open2000, Open2002.) So when you compile against Excel 2002, you MAY be
referencing some of these new methods. But when your program runs under
Excel 2000, those new methods won't exist and your program will crash.

So how do you know if you are using new methods? Use OleView (which I got
with MS Visual C++ 6.0) or some similar program to look through the Excel
type library and see what methods have changed from 2000 to 2002. For
methods that have changed, you'll have to use late binding.

Let me know if you want more of an explanation of late binding.

Really the best thing to do is get Excel 2000 and reference/compile against
it. There should not be any problems with you running it on the same machine
at 2002. I had Word 6.0, 97, 2000 and 2003 all on the same machine,
switching back and forth with no problems.

Here is Microsoft's official statement on all this:
INFO: Writing Automation Clients for Multiple Office Versions
http://support.microsoft.com/default.aspx?scid=kb;EN-US;244167

FYI, there really isn't an SDK you purchase. There was the Office Developer
Edition, but it just had some extra tools, but nothing that would magically
make it easier to work with multiple versions of Office. All the
documentation you need is on MSDN for free.
--
Tom Winter

Post by Nick Hebb
I posted this in
http://groups-beta.google.com/group/microsoft.public.excel.programming?hl=en
to no avail, so hopefully I'll have better luck here...
I'm developing a VB6 COM Add-in for Excel on a machine that current has
Office XP installed, which means that my VB6 project sets a reference
to the Excel 10.0 (2002/XP) object library.
I would like my add-in to be backward compatible with Excel 2000, which
uses the Excel 9.0 (2000) object library. In order to ensure this, as
1. Check the Object libraries for 2000 and XP looking for any
differences that might effect my code. Then cross my fingers and hope
for the best.
2. Buy and install Excel 2000 in order to get access to the older
library.
3. Obtain a copy of the Office 2000 SDK. Unfortunately, I can't seem
to locate this anywhere on MSDN.
Option 1 looks like my best bet. Has anyone tried this with success?
Any gotchas to watch out for.
Option 2 isn't appealing because of the cost and the configuration
headaches. If I had VPC or VMWare it would be less of an issue, but I
don't have either.
Option 3 would be optimal, but I don't know where to obtain a copy of
this SDK. Does anyone know if there are still copies available for
download?
Any advice would be greatly appreciated.
Thanks,
Nick

[Nick Hebb]

Thanks Tom. Your advice is really helpful.

I'm still skeptical about having multiple versions of Office on the
same machine. I think the order in which they are installed makes a
big difference. That is, I might need to uninstall Office 2002,
install 2000, then re-install 2002.

If I do decide to try late binding, then I explicitly _don't_ set a
reference to the library in the project, correct?

[Tom Winter]

Installation order is probably important. I've always installed them from
lowest to highest. Can't tell you want would happen if you didn't, but it
probably wouldn't be that big a deal, as long as they are in separate
folders of course.

The main thing about late binding is Dim'ing As Object. If you are going all
late binding, then you should get rid of the reference so you don't
accidently use early binding. Here is something I wrote up a while ago that
explains things:

How you get the object doesn't matter. An OBJECT is not late
bound or early bound. An object is just an object. It's METHOD CALLS that
are early or late bound. When you are calling methods (or properties) on an
object that has been DIM'ed as some specific object type, the method calls
are early bound. When the object has been DIM'ed AS OBJECT, the method calls
are late bound. Take a look at this:

Dim oDocumentsEarly As Word.Documents

Dim oDocumentsLate As Object

Set oDocumentsEarly = oWord.Documents ' Doesn't matter where we got oWord
from....

oDocumentsEarly.Open "Something.doc" ' This call is early bound.

Set oDocumentsLate = oDocumentsEarly

oDocumentsLate.Open "SomethingElse.doc" ' This call is late bound.
--
Tom Winter

Post by Nick Hebb
Thanks Tom. Your advice is really helpful.
I'm still skeptical about having multiple versions of Office on the
same machine. I think the order in which they are installed makes a
big difference. That is, I might need to uninstall Office 2002,
install 2000, then re-install 2002.
If I do decide to try late binding, then I explicitly _don't_ set a
reference to the library in the project, correct?