Re: Making MFC application to expose COM interfaces
- From: "Brian Muth" <bmuth@xxxxxxxx>
- Date: Tue, 20 Dec 2005 15:22:36 -0800
> So what you mean to say is that if the MFC application, i'll call MFC
> Server since it is going to expose interfaces, that has to expose the
> interfaces as IFunc1, IFunc2 and iFunc3, only one of the interfaces can
> be dispatch interface and the rest be normal vtable interfaces ?
>
I believe under MFC you always get an dispinterface. MFC is not capable of
vtable-type interfaces. You can see this yourself if you create an MFC
application and insert two MFC classes that support automation. Note that
you will also get two separate coclasses defined, one for each of the
dispinterfaces.
You haven't made a case for supporting multiple interfaces (that is,
interfaces other than IDispatch). However, if that is a requirement, I agree
with you that you are better off using ATL.
Combining MFC with ATL is ugly business, IMHO, and you should strive to
avoid it. If you insist on proceeding down this painful path, consider
reposting in microsoft.public.vc.mfcole to get the MFC perspective on this
problem.
> Or all of the interface methods in IFunc1/2/3 must be exposed as one
> disp interface IFunc.
Exactly. Why not?
>
> Also i tried your suggestion in the previos post.
> I created a MFC class with automation support CFunctionality [derived
> from CCmdTarget with interface map macros, using the wizard]. And it is
> this way it must work.
>
> I double click the MFC Server from explorer. It launches as a MFC
> application and during the InitInstance, i cocreate the non-automation
> COM OOP server [i'll call COM OOP Client] that is the client for this
> MFC Server, and then after cocreating the COM OOP Client, MFC server
> calls Initialize interface method on it. In the Initialize method, the
> COM OOP Client does a cocreate of the MFC Server for one of the
> interfaces it exposes to call methods at a later time. But when the COM
> OOP Client cocreates, that instantiates the second instance of the MFC
> Server, so the problem here is how to make the MFC Server CO singleton
> ???
No, as long as your security context on the client side is unchanged, you
will only have one MFC Server, but you will have two instantiated objects
residing in the same process. If the two instantiated objects need to share
resources, this is quite trivial, since you can track these resources are
either global variables or static class member variables. Avoid designing a
singleton (a common mistake novices make. They are completely unnecessary.).
Perhaps you should repost in microsoft.public.vc.mfcole anyway, since this
is no longer an ATL question.
HTH
Brian
.
- References:
- Making MFC application to expose COM interfaces
- From: VivekR
- Re: Making MFC application to expose COM interfaces
- From: Brian Muth
- Re: Making MFC application to expose COM interfaces
- From: VivekR
- Re: Making MFC application to expose COM interfaces
- From: Brian Muth
- Re: Making MFC application to expose COM interfaces
- From: VivekR
- Making MFC application to expose COM interfaces
- Prev by Date: Re: Making MFC application to expose COM interfaces
- Next by Date: Base64Decode in VS6
- Previous by thread: Re: Making MFC application to expose COM interfaces
- Next by thread: Late binding
- Index(es):
Relevant Pages
|