IDL -> library -> coclass -> interface declaration
Jason S
coclass listings in the library section of an IDL file. What does this
actually do? If I have an object X that implements IPersistStream, is
there value in putting IPersistStream into this section of the IDL
file?
My impression of what you have to do to implement an interface in C++
is to add it to the class inheritance in the class declaration, add &
implement the appropriate methods, and make sure the class responds to
the IID using QueryInterface e.g. by putting it in the BEGIN_COM_MAP()
section. I'm not quite sure why I would or would not add this to the
coclass section of the IDL file, though.
Igor Tandetnik
> I'm confused about the "interface" keyword in the context of the
> coclass listings in the library section of an IDL file. What does this
> actually do?
It writes to the type library the fact that a coclass implements an
interface, or supports an outgoing interface (if [source] attribute is
present).
> If I have an object X that implements IPersistStream, is
> there value in putting IPersistStream into this section of the IDL
> file?
Usually, no. Clients that actually consult type libraries are usually
limited to only using automation-compatible interfaces, so only such
interfaces are worth mentioning under coclass.
> I'm not quite sure why I would or would not add this to the
> coclass section of the IDL file, though.
It allows certain clients to provide some syntactic sugar. For example,
VB treats coclass name as synonymous with coclass' [default] interface
as declared in the type library. Also, VB's "Dim With Events" syntax
automatically sinks events from the coclass' default outgoing interface
(one marked [source, default] in the TLB).
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Jason S
> > If I have an object X that implements IPersistStream, is
> > there value in putting IPersistStream into this section of the IDL
> > file?
>
> Usually, no. Clients that actually consult type libraries are usually
> limited to only using automation-compatible interfaces, so only such
> interfaces are worth mentioning under coclass.
OK, thanks a bunch! That helps.
Hmm. That brings up another question. I know that you can have
interfaces which are automation-compatible but not late-binding
(IDispatch-derived). Does that mean clients that use such interfaces
must figure out how to bind to them at compile-time, or is it possible
to work some magic so that they can handle run-time binding? (not that
I would try myself, just curious)
Igor Tandetnik
> Hmm. That brings up another question. I know that you can have
> interfaces which are automation-compatible but not late-binding
> (IDispatch-derived).
Yes. You can have an interface derived from IUnknown and marked with
[oleautomation] attribute. VB can use these, scripting languages can't.
> Does that mean clients that use such interfaces
> must figure out how to bind to them at compile-time
Roughly, yes.
> or is it possible
> to work some magic so that they can handle run-time binding?
You can use ITypeInfo::Invoke. It knows how to build appropriate stack
frames based on TLB description of the interface. There's also an
undocumented DispCallFunc API - see
IDispEventSimpleImpl::InvokeFromFuncInfo in atlcom.h. This one allows
you to provide parameter descriptions manually, if you don't have a TLB
handy. And of course, you can build the stack frame by hand, but that's
not for the faint of heart.
Jason S
> > or is it possible
> > to work some magic so that they can handle run-time binding?
>
> You can use ITypeInfo::Invoke. It knows how to build appropriate stack
> frames based on TLB description of the interface.
!!!! That seems like a good tool to have in the bottom of one's bag of
tricks. Thanks!