Re: Help! MIDL2039
Well, you have two alternatives:
1. Do not extend the original interface - copy/paste its
methods in front of any new methods you are going to add.
In this case you shouldn't implement the original interface
on the same object as the new interface.
2. Lose the dual part and have your interfaces derive
from IUnknown instead of IDispatch. You can have a
separate implementation of IDispatch on the same
object for late-bound clients. (That can use a hidden
dual interface for convenience of implementation.)
Microsoft MVP [VC], MCSD
MVP VC FAQ: http://vcfaq.mvps.org
"David Stuart" <firstname.lastname@example.org> wrote in message
On Mon, 12 Mar 2007 11:01:06 -0700, Alexander Nickolov wrote:
Technically, a dual interface cannot derive from another
dual interface. This violates the dual interface contract -
that the functionality exposed through the vtable is equivalent
to the functionality exposed via the vtable methods above
IDispatch (and more precisely it violates the base interface's
dual contract, because the IDispacth impementation would
be richer than the vtable for the base dual interface).
In practice this has no adverse consequences and is therefore
an accepted (or at least tolerated) practice. You'll have to live
with the warning however.
Hi Alexander, thanks for helping ..
Personally I find the warning is important, because if I ignore this
warning, the compiler will crash at a later point (see my later post on
So, how would one achieve what I want to do without violating the dual
interface contract (as you put it)? Does this mean the base class should
have the 'dual' attribute and not the derived? Or vice versa?
Maybe what I am trying to do is not a common practice?
Is it not normal to try to extend a type which is provided to you in
a DLL/TLB? If not, what are the usual alternatives/workarounds?
David Stuart, FirstHand Technologies
Address: 300 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5