问题
Reviewing our code I've found a curious definition in one of .idl files:
[
object,
uuid(uuidhere),
dual,
nonextensible,
oleautomation,
hidden
]
interface IOurInterface : IUnknown {
//methods here
};
How can an interface derived directly from IUnknown
possibly be a dual interface? Will anything break if I remove the dual
attribute?
回答1:
In this answer to another question concerning marshaling user voyce points to this article that basically states the following:
When any interface (IDispatch-derived or not) is marked either dual
or oleautomation
(or both) it is treated specially when RegisterTypeLib()
is invoked (which is typically done by DllRegisterServer). For each such interface an HKCR\Interface{InterfaceId} key is created under which {00020424-0000-0000-C0000-000000000046} class is referenced as proxy/stub. This class id corresponds to typelib marshaller also known as oleautomation marshaller.
回答2:
I can't see a reason that that would work, given the docs here: http://msdn.microsoft.com/en-us/library/aa366807(VS.85).aspx
Interfaces identified by the dual attribute must be compatible with Automation and be derived from IDispatch. This attribute is not allowed on dispinterfaces.
It could be that the [dual]
attribute implicitly adds IDispatch
to the interface.
What you could do is check the code implementing the interface (assuming this is ATL) if it derives from IDispatchImpl
. If so, it actually responds to QI for IDispatch
and might be used as such.
Another alternative is to instantiate an object implementing IOurInterface
and QI it for IDispatch
-- if it succeeds, you probably can't remove it.
Actually, come to think of it, maybe [dual]
doesn't technically require that you derive from IDispatch
as long as you implement both your custom interface and IDispatch
?
来源:https://stackoverflow.com/questions/1636148/any-sense-in-marking-an-iunknown-derived-interface-as-dual-in-idl