Reverse compatibility

[rebkwez]

Hi,

I have an add-in for Outlook written in VB6. I was testing it with
Outlook 2000 and everything worked fine. I then installed Outlook 2003
on my machine and the add-in was working fine. Had to make a few code
changes here and there but for the most part it was the same. I wrote
an installer and had someone test it. It no longer works on 2000. I
unistalled 2003 on my machine and then re-installed 2000. I discovered
that the OnConnection funtion was failing when I try to initiate a
variable and I recieved an error "Automation error Library not
registered."

Below is the code that is causing the error. The error occurs when I
try to set OLInstance.

Any suggestions as to why this is happening? Did installing Outlook
2003 and using those librarys effect backwards compatibility? How does
one properly code and add-in to work for all versions of Outlook?

Thanks
Elliot


Private OLInstance As Outlook.Application

Private Sub AddinInstance_OnConnection(ByVal Application As Object,
ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, ByVal
AddInInst As Object, custom() As Variant)

Set OLInstance = Application

 

[Ken Slovak - [MVP - Outlook]]

Normally you would compile only with the earliest version of Outlook that
you intend to support. That's if you use early binding.

What I and many other developers do is set up a virtual machine with Outlook
2000 on it and compile on that VM (I use VMWare, you can also use Virtual
PC). I develop and test from the IDE on my main dev machine which is running
Outlook 2003 and then compile on the Outlook 2000 VM.

If you have already recompiled on an Outlook 2003 machine you would have to
break binary compatibility of your project when you compile again on Outlook
2000.

 

[rebkwez]

Ken,

Thanks for the reply. Question though, how does one "break binary
compatibility" on a project?

Thanks,
Elliot

 

[Ken Slovak - [MVP - Outlook]]

In VB 6: Project, Properties, Component tab, Version compatibility section.
Normally it would be set to Binary compatibility so that each new
compilation won't get a new CLSID. Once you break the public interface of
the code that will no longer be true. If you go ahead with the compilation
after getting the compatibility warnings that setting will become None.