To do this, I created a basic interface IProtecsAddIn in the app's type
library, that should be implemented by each server CoClass. To ease
implementing the add-in, I want to provide a unit with a basic object
TProtecsAddIn, that provides default implementations of the IProtecsAddIn.
TProtecsAddIn derives from TAutoObject.

Then, I wanted to create a sample add-in. So, with the wizard, I created an
automation server, added the app's type library to the used libraries in the
TLB editor, and I manually added the IProtecsAddIn interface to the Add-in's
CoClass's list of implemented interfaces. I also changed the derivation of
the add-ins implementation class from TAutoObject to TProtecsAddIn. Finally,
I pressed the 'refresh implementation' button in the TLB editor.

Now the TLB editor added all IProtecsAddIn methods to the implementation
class. I don't want that, because the TProtecsAddIn class already provides a
basic (read: virtual) implementation of these methods and I don't want to
reintroduce them. I understand that the TLB editor does so, because that's
it default behaviour and it would take compilation to know that those
methods have been implemented already.

Now I reckon, there should be a way out of this, since DataSnap is implement
the same way. Each DataSnap server implements IAppServer, but I never see
the TLB editor generate code for the IAppServer methods. It doesn't need to,
because they are already implemented in the base class.

Can anybody tell me how to obtain this behaviour? Thanks for reading this
lenghty text anyway :-) !!!

Peter Laman

I use a very similar approach to creating plig-ins (add-ins) for a large application. I successfully created several hierarchies of add-ins.

I think your problem with the wizard is that you explicitly tell the subclass to implement your common interface. You don't have to do that, because (in Delphi) the subclass will automatically inherit implementation of all interfaces that its superclass implemented.

For example, I can create an interface IPlugIn in my type library. Then I create a base class for all plug-ins: CPlugIn, which explicitly implements IPlugIn (caveat: you can create this base class using the reagular COM object wizard, but you have to remove the instantiation code in the initialization section!).

..
type
     TCPlugIn = class (TAutoObject, IPlugIn);
..

Now you use the COM wizard to create an actual COM plug-in, say CMyPlugIn1. You derive it (in the wizard) from, say Automation Object. It comes with a default (empty) interface, which you leave in place. What you do later is simply manually replace TAutoObject in the class def with TCPlugIn - and your new class inherits the implementation of IPlugIn automatically:

..
type
    TCMyPlugIn1 = class (TCPlugIn, IMyPlugIn1);
..

If you do it this way, the wizard will not insert any IPlugIn methods in your new class, and you are free to add (manually) only those that you want to override (you can copy their defs from the _TLB).

Hope this helps.

                        Igor

Up to now I have already used the method you describe, but now I wish to add
the basic interface to CoClass in the TLB editor on the "implements" tab.
The reason is, that the application should be able to register new Add-ins
itself. To do this the user gets a dialog where he can select a folder and
then the Add-in server EXE/DLL's should be listed. If the TLB indicates that
a CoClass implements the basic Add-in interface, I can determine whether an
EXE or DLL contains one or more Add-ins by calling LoadTypeLibrary and then
inspecting its CoClasses and the interface GUIDs it implements, without
having to register the server first and instantiate its CoClasses to
QueryInterface them.
But if I add the interface in the TLB editor, the wizard automatically adds
all of its methods.

HEY!! As I'm typing this, I realize that I can easily work around the
problem, by introducing a new interface, say IProtecsAddInSignature, from
which the old basic interface IProtecsAddIn derives. If
IProtecsAddInSignature contains no methods, I can safely add it to the
"implements" list of the CoClasses and still have a way to determine whether
a CoClass is an add-in or not.
Problem solved.