Re: Dual interface
"George" <George@discussions.microsoft.com> wrote in message
news:A72EE964-74A7-42FE-B45F-E9C27535F792@microsoft.com
A further question from (1) -- to implement dual interface is easy,
i.e. making the component implement both a customized interface and
also implementing IDispatch. So, I think since it is easy, every COM
component should always implement it and be a dual interface.
A lot of things are easy. This doen't mean you have to put each and
every one of them into every program you make, whether you need them or
not.
Why
implementing dual interface is not mandatory
Wearing hats is not mandatory here in the US, even though it's easy. Do
you think it should be?
-- i.e. for some other
reasons, developer will not implement dual interface, has some
disadvantages to implement dual interface?
Well, a component can only implement one dual interface. If all
interfaces were dual, no component could implement more than one.
A dual interface must use automation-compatible parameter types (since
when called via IDispatch::Invoke, parameters come packed into
VARIANTs). Many interfaces benefit from using non-automation types.
Consider for example IStream::Read.
The rule is simpler. If it doesn't implement IDispatch, it is not
dual interface. If it does, then it is dual interface.
Except when it's a dispinterface.
I am lost the context. :-)
Your exception rule "when it's a dispinterface" -- is for "If it
doesn't implement IDispatch, it is not dual interface" or is for "If
it does, then it is dual interface"?
The latter. Not every component that implements IDispatch also
implements a dual interface. It could be implementing a dispinterface
instead.
--
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