Board index » cppbuilder » DUALINTERFACE overhead in BCB 5.0?

DUALINTERFACE overhead in BCB 5.0?

When adding additional interfaces to an existing CoClass definition in a
type library (.tlb) in BCB5.0 --- the environment does some great things to
help you on your way...among them:
1)  The CoClassImpl declaration (in "CoClassImpl.h") is updated to inherit
the new interface via the DUALINTERFACE_IMPL macro.
2)  A new DUALINTERFACE_ENTRY is added for the interface to the COM_MAP.

This compiles in and works great.  My question was whether or not there is
unnecessary overhead now added to the component --- since IDispatch support
appears to be provided for by use of these "DUALINTERFACE" style macros?
I'm developing an InProc server and have no need of automation support.

Am I safe just to replace these entries with 1)  Direct inheritance from
ISomeNewInterface and 2) a standard COM_INTERFACE_ENTRY in the COM_MAP?

tks.

 

Re:DUALINTERFACE overhead in BCB 5.0?


The size of your component is alittle bigger (Now that it is derived from
IDispatchImpl) but if none of you client code uses the IDispatch interfaces,
then I would not consider the object has any unnecessary overhead.

You could uncheck the automation flag & maybe the dual interface checkboxes
in the TLB editor to remove this support as well.

Mark

Quote
"Casper" <fsm...@novatel.ca> wrote in message news:3a7af06f$1_1@dnews...
> When adding additional interfaces to an existing CoClass definition in a
> type library (.tlb) in BCB5.0 --- the environment does some great things
to
> help you on your way...among them:
> 1)  The CoClassImpl declaration (in "CoClassImpl.h") is updated to inherit
> the new interface via the DUALINTERFACE_IMPL macro.
> 2)  A new DUALINTERFACE_ENTRY is added for the interface to the COM_MAP.

> This compiles in and works great.  My question was whether or not there is
> unnecessary overhead now added to the component --- since IDispatch
support
> appears to be provided for by use of these "DUALINTERFACE" style macros?
> I'm developing an InProc server and have no need of automation support.

> Am I safe just to replace these entries with 1)  Direct inheritance from
> ISomeNewInterface and 2) a standard COM_INTERFACE_ENTRY in the COM_MAP?

> tks.

Re:DUALINTERFACE overhead in BCB 5.0?


I thought that would work too; but those flags are disabled for all but the
library's first interface definition.   To repeat, just open 5.0 and select
New | ActiveX Library, followed by New | Com Object.  Now add a second
interface to the project Type Library (.tlb); you'll see that 'dual'  and
'oleautomation' flags are checked and disabled for this new interface ---
and the impl code added to support the interface uses the DUALINTERFACE...
macros as mentioned below.  Frustrating.  Specifying "no oleautomation" in
the COM Object wizard, and changing the Parent Interface attribute (from
IDispatch to IUnknown) for the second interface have no effect.

Anyhow, it does work to just go in and modify the macros by hand.... I just
prefer not to muck with auto-generated code unless it's really necessary.
tks for your input Mark.

Quote
"Mark Finkle" <mfin...@enron.com> wrote in message

news:95etqd$31p3@bornews.inprise.com...
Quote
> The size of your component is alittle bigger (Now that it is derived from
> IDispatchImpl) but if none of you client code uses the IDispatch
interfaces,
> then I would not consider the object has any unnecessary overhead.

> You could uncheck the automation flag & maybe the dual interface
checkboxes
> in the TLB editor to remove this support as well.

> Mark

> "Casper" <fsm...@novatel.ca> wrote in message news:3a7af06f$1_1@dnews...
> > When adding additional interfaces to an existing CoClass definition in a
> > type library (.tlb) in BCB5.0 --- the environment does some great things
> to
> > help you on your way...among them:
> > 1)  The CoClassImpl declaration (in "CoClassImpl.h") is updated to
inherit
> > the new interface via the DUALINTERFACE_IMPL macro.
> > 2)  A new DUALINTERFACE_ENTRY is added for the interface to the COM_MAP.

> > This compiles in and works great.  My question was whether or not there
is
> > unnecessary overhead now added to the component --- since IDispatch
> support
> > appears to be provided for by use of these "DUALINTERFACE" style macros?
> > I'm developing an InProc server and have no need of automation support.

> > Am I safe just to replace these entries with 1)  Direct inheritance from
> > ISomeNewInterface and 2) a standard COM_INTERFACE_ENTRY in the COM_MAP?

> > tks.

Other Threads