Re: Problem marshalling interface pointer into local server

From:

"Alexander Nickolov" <agnickolov@mvps.org>

Newsgroups:

microsoft.public.vc.atl

Date:

Tue, 18 Jul 2006 09:47:54 -0700

Message-ID:

<#10#qnoqGHA.1852@TK2MSFTNGP03.phx.gbl>

It'd be so much easier for everybody if you only post your
questions once... Check your misplaced thread again and
then continue any discussion here.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Angela Yan" <yanyan9@hotmail.com> wrote in message
news:OiucGLiqGHA.1976@TK2MSFTNGP04.phx.gbl...

Hi,

Thanks for your reply.

I replied my 'misplaced' post. But just in case it is too deep down the
valley. I copied the reply here together with some of the findings.

- From "Alexander Nickolov"

...
You'll probably want to group all shared interfaces as a separate
project that only produces a proxy/stub DLL (or a type library,
whatever is appropriate). Then in the other projects you only
refer to those interfaces, but do not generate any marshaling info
for them. That means you import the shared IDL and importlib()
the shared type library.

- My reply to the post:

So am I correct to say that there are 2 methods to deal with the problem:

1. Compile the common IDL file that containing all the shared interfaces
into a typlib. Then all the projects import the IDL file and the typlib
in their respective 'main' IDL files. During deployment, it needs to
register the common typlib (hmm.. how to register??) and take care of the
registration refCount issue.

2. Compile a DLL project that describes all the shared interfaces. Then
all the projects can use wizard "implement interface" to point to that
DLL project and implement the respective interfaces. The imported DLL
project path will be auto added into stdafx.h. In this case, does it need
to take care refCount issue for the common DLL during deployment??

My findings to option 1:

I've managed to compile the common IDL into a typeLib and register it
using "LoadTypeLib() and RegisterTypeLib()". But according to the MSDN and
I also confirmed subsequently that during the registeration of the
TypeLib, only dispatch interface type and dual interface type will go into
registry HKCR->Interface key.

All interfaces in the common IDL file inherits from IUnknown interface,
the only difference is that some is marked with 'dual' attribute (I am not
sure whether it is correct..). I noticed that after registering the
typelib, only those interfaces marked with 'dual' attribute will go into
registry but not the other interfaces. Thus my local server still lack of
the marshalling information for those non-dual IUnknown interfaces.

Can please kindly point out which step I did is wrong? Compile the IDL?
Register the TypeLib or..?

Thank you very much.

Angela

"Alexander Nickolov" <agnickolov@mvps.org> wrote in message
news:%23SqctJcqGHA.4912@TK2MSFTNGP05.phx.gbl...

Neither. Make a sepaarte proxy/stub DLL with B's marshaling
support. Also see my reply on your other (misplaced) post.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Angela Yan" <yanyan9@hotmail.com> wrote in message
news:e$E5woPqGHA.3244@TK2MSFTNGP03.phx.gbl...

Hi,

Did you register the proxy-stub for interface B? Remember, it is not
marked as automation-compliant.

Hmm.. No, I didn't register the proxy/stub for interface B. The local
server only 'uses' the interface B, but did not implement it. As for the
client of the local server, which is an in-proc dll, it also does not
register the proxy/stub for interface B. Interface B is in defined in a
common IDL file that is shared between several COM servers. I
experimented it and confirmed that once the proxy/stub for interface B
gets registered, everything works fine.

But I have another question here. I am not sure which COM server should
register the proxy/stub for interface B in this case, since it is in a
common IDL file that several COM servers will 'import' from. And COM
servers may include 2 or more local servers.

In this case, should I register one or both local server's proxy/stub?
Or, should I compile the common IDL file into a
common typelib and register it? Or is there any other recommendation?

Thank you.

Angela

"Brian Muth" <bmuth@mvps.org> wrote in message
news:OVP7Kk1pGHA.3564@TK2MSFTNGP03.phx.gbl...

Can you explain more on why a dual interface cannot accept other
interface, other than IUnknown, as its method's paramter?

A dual interface supports IDispatch, and therefore the parameters must
be ole-automation compliant. Passing a custom interface is not
ole-automation compliant. But you can pass IDispatch* and IUnknown*.

And actually I tried the method of passing the IUnknown of Interface B
over to the local server, and local server then QI to get the actual
interface B. However, although my client does receive the QI from the
local server and returns the interface B, the local server cannot get
the interface B over. The error code is E_NOINTERFACE.

Did you register the proxy-stub for interface B? Remember, it is not
marked as automation-compliant.

By the way, I am not using attributed ATL. At least, when I created
the project, I unticked the 'attributed' check box... :p

Excellent.

Brian