Re: Problems with IDispatchImpl

From: Per Nilsson (perfnurtAThotmailDOTcom)
Date: 02/23/04 

Date: Mon, 23 Feb 2004 23:41:32 +0100

Wow, I got it to work.

Thanks a lot!

/Per N.
perfnurt at hotmail dot com

"It was a work of art, flawless, sublime. A triumph equaled only by its
monumental failure."
- The Architect

"Alexander Nickolov" <agnickolov@mvps.org> skrev i meddelandet
news:%233TvIYl%23DHA.2824@tk2msftngp13.phx.gbl...
Wait a second, I didn't recognize you are implementing a third
party interface (and one from Visual Studio at that...). I thought
you have your own dual interface defined in another type library.
You have to check if this IApplication is indeed a dual interface.
Find its entry under HKCR/Interface, get the type library GUID,
find it under HCKR/TypeLib and then open it in OleView. The
interface definition will clearly say if this is a dual interface or
a pure dispinterface. If it is indeed dual, all you need to do is
supply the LIBID you already found and the corresponding major/
minor version numbers for the type library. I expect it is dual,
since you are getting it off header files :)... If it is a pure dispatch
interface, you can't get ATL support - bite the bullet and implement
IDispatch by hand (based on your previous post, I doubt this is
the case). 

-- 
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"Per Nilsson" <perfnurtAThotmailDOTcom> wrote in message
news:%23jiZoqk%23DHA.1424@TK2MSFTNGP12.phx.gbl...
> Thank you. Yes its like you mention in the second section. IApplication is
> the interface I wish to implement.
> As for the type library and LIBID, I actually have no clue what/where they
> are.
>
> All I have (so far :-) ) is the definition of IApplication:
> ...\VC98\Include\ObjModel\APPAUTO.H
> and the definition of IID_IApplication:
> ...\VC98\Include\ObjModel\APPGUID.H
>
> I thought that knowing these should be sufficient as I have no trouble
with
> the non-IDispatch  related methods (ie I can handle
> when the add-in calls for example IApplication::AddCommand), but should
the
> client call the IDispatch methods, well,
> I get a bit lost.
>
> -- 
> /Per N.
> perfnurt at hotmail dot com
>
> "It was a work of art, flawless, sublime. A triumph equaled only by its
> monumental failure."
> - The Architect
>
> "Alexander Nickolov" <agnickolov@mvps.org> skrev i meddelandet
> news:u%23YUmRk%23DHA.2212@TK2MSFTNGP10.phx.gbl...
> The IDispatch methods are indeed implemented by IDispatchImpl,
> but notice - in your base class. If IApplication is essentially as
> same as IDispatch, what you end up is deriving from IDispatch
> twice - once through IDispatchImpl and your dual interface, and
> again directly from IApplication. True, the second is not IDispatch
> really (so you can get away with it), but you don't implement it
> so the compiler complains. I suggest you simply drop your
> IApplication interface since it seems to add nothing to the picture.
> You already implement IDispatch through your dual interface (and
> you are not allowed to expose multiple IDispatch implementations
> on the same object anyway).
>
> Now, reading over again, I'm not sure if you didn't mean something
> else. Perhaps IApplication is the real dual interface you want to
> implement. In that case replace IApplicationStub with IApplication
> both in the IDispatchImpl argument and the interface map, then
> drop the explicit derivation from IApplication. IApplicationStub
> disappears entirely - you can safely remove it from the IDL file
> as well, and change the coclass to specify IApplication instead.
> Don't forget to importlib() the correct type library as needed. And
> don't forget to change the LIBID in the IDispatchImpl template
> (and specify explicit version perhaps) too - to the type library
> that defines your IApplication interface.
>
> -- 
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@mvps.org
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> "Per Nilsson" <perfnurtAThotmailDOTcom> wrote in message
> news:uiWTqRj%23DHA.3068@tk2msftngp13.phx.gbl...
> > Hiya,
> >
> > I've implemented the Visual Studio Application model (VC6) in a small
app
> > that I can test add-ins with. All-in-all it worked fine (ie direct calls
> of
> > IApplication etc methods), except IDispatch calls (I simply done dummy
> > implemenation of the IDispatch methods), besides,I thought I should do
it
> > nicer, more ATL-ish. Being fairly new to ATL (its also an
exercise/excuse
> to
> > work with ATL) I can't get the implementing of the IDispatch straight.
> >
> > With a class declaration as:
> >
> > class ATL_NO_VTABLE CApplicationStub :
> >     public IApplication, // The iface I want to implement (it defines
the
> > various IDispatch methods as pure virtual)
> >     public CComObjectRootEx<CComSingleThreadModel>,
> >     public CComCoClass<CApplicationStub, &CLSID_ApplicationStub>,
> >     public IDispatchImpl<IApplicationStub, &IID_IApplicationStub,
> > &LIBID_ATLTestLib>
> > {
> > public:
> >   CApplicationStub()
> >   {
> >   }
> >
> >   DECLARE_REGISTRY_RESOURCEID(IDR_APPLICATIONSTUB)
> >   DECLARE_PROTECT_FINAL_CONSTRUCT()
> >   BEGIN_COM_MAP(CApplicationStub)
> >     COM_INTERFACE_ENTRY(IApplicationStub)
> >     COM_INTERFACE_ENTRY(IDispatch)
> >   END_COM_MAP()
> >   // etc...
> >
> >
> > I keep getting "cannot instantiate abstract class due to .... long
> __stdcall
> > IApplication::GetTypeInfoCount(unsigned int *)" and the other IDispatch
> > methods as well.
> >
> > I thought these methods are implemented by the IDispatchImpl template
> class.
> > Well, obviously not since I get the error...
> >
> > What am I stupidely missing? (Im instantiating using the CComObject< >
> > template)
> >
> > As a workaround I've tried to  implement the IDispath methods like this
> > STDMETHOD(GetTypeInfo)(UINT itinfo, LCID lcid, ITypeInfo** pptinfo)
> > {
> >     return IDispatchImpl<IApplicationStub, &IID_IApplicationStub,
> > &LIBID_ATLTestLib>::GetTypeInfo(...params...);
> > }
> > but that didn't do the trick as the client's Invoke will still fail. The
> > m_pInfo member if the CComTypeInfoHolder in question is NULL.
> >
> > Any ideas (a firm kick in the right direction will do :-)?
> >
> > Thanks
> >
> > -- 
> > /Per N.
> > perfnurt at hotmail dot com
> >
> > "It was a work of art, flawless, sublime. A triumph equaled only by its
> > monumental failure."
> > - The Architect
> >
> >
>
>

Relevant Pages

  • Re: Problems with IDispatchImpl
    ... > you have your own dual interface defined in another type library. ... > You have to check if this IApplication is indeed a dual interface. ... > IDispatch by hand (based on your previous post, ... >> perfnurt at hotmail dot com ...
    (microsoft.public.vc.atl)
  • Re: Problems with IDispatchImpl
    ... the interface I wish to implement. ... The IDispatch methods are indeed implemented by IDispatchImpl, ... If IApplication is essentially as ...
    (microsoft.public.vc.atl)
  • Re: Problems with IDispatchImpl
    ... The IDispatch methods are indeed implemented by IDispatchImpl, ... If IApplication is essentially as ... You already implement IDispatch through your dual interface (and ...
    (microsoft.public.vc.atl)
  • Re: Problems with IDispatchImpl
    ... you have your own dual interface defined in another type library. ... You have to check if this IApplication is indeed a dual interface. ... IDispatch by hand (based on your previous post, ... > The IDispatch methods are indeed implemented by IDispatchImpl, ...
    (microsoft.public.vc.atl)
  • IDispatch* , COM Server(LOCAL_SERVER), event data and C#.NET
    ... I have one main inbound interface called ... If IDispatch is the answer, I already did the following, ... I did code following C++ wrapper class for the _ICallInfo impl. ... // object before calling the base class. ...
    (microsoft.public.dotnet.framework.interop)
Loading