VB Forum / COM / July 2003

I think the answer is that you have an interface that you cant break.
However you can add extra functions.

So I guess if you have a function called

GetClientInfo(x)

The way forward is to now add functions like

GetClientInfoEx(x,y,z)

just like microsoft does.

Dont touch the old interface, build a new one so that new clients can use
it.

Probably easier to develop a new class in VB and test, and if I'm not
mistaken you can port the new functions to the COM object you using now, but
you can mess with existing functions.

Then old and new programs can then use the new COM class.

Good idea to make a backup first.

Hi Alan

Use typelibs  you can change the whole interface and vb won't say a
thing - I do it all the time. As long as the uuid above the interface
(IID) remains the same vb will assume that the interface is the same.
The only thing you MUST do is re-edit ALL your components that depend on
that interface / implement it.

If you cannot recompile all clients but only the server try
adding a new interface (the way COM would like it to be done).

I am using this approach for nearly three years and it works perfectly.

This approach won't save you from the problems of maintaining an already
distributed codebase but will (at least) help you to make VB more
"predictable".

BTW: All my components use "binary compatiblity" with a reference file
that is  a copy of the last change (-> new class, new interface, new
anything in the interface). This way you always have your last
compatibility-file saved.

HTH, Jens

The whole idea of binary compatibility is that none of the dependent
components have to be recompiled.  Each component can actually evolve
separately.  The only thing you need to worry about is that the components
on which you component is built are installed with at least the versions you
used when compiling.  This is what makes it all so great.  No more
compilation-rippling.