Any sense in marking an IUnknown-derived interface as dual in IDL?

Question

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?

score 3 · Accepted Answer · edited May 23 '17 at 12:07

3

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.

edited May 23 '17 at 12:07

Community

1
1

answered Nov 16 '09 at 12:43

sharptooth

167,383
100
513
979

Ah yes, that's right. Since you already had `oleautomation` I figured that was implicit... I didn't know the exact specifics, though, so thanks for the follow-up! – Kim Gräsman Nov 16 '09 at 16:52
And I still think you should make sure the object doesn't currently respond to QI for `IDispatch` before you remove it. – Kim Gräsman Nov 16 '09 at 16:58
Yes, I completely agree about the QI responce with IDispatch. – sharptooth Nov 17 '09 at 06:08

score 1 · Answer 2 · answered Nov 02 '09 at 06:11

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?

Any sense in marking an IUnknown-derived interface as dual in IDL?

2 Answers2

Linked