Re: IUnknown, Identity rule for 'nested objects'

erface. It is perfectly fine, and quite common, to have a


mplemented by a different object with its own distinct COM


When you 'perfectly fine', are you also including the case where
Marshalling is involved?. My understanding is, marshallers call QI().
Let me give an example(x.dll),

CoClass A CoClassB
{ {
    Interface IA1; Inteface IB1;
    Interface IA2; Interface IB2;
}; };

Assume a method of IA1 returns pointer to IB1 by calling
CoCreateInstance(). Then marshaller may call like this. pIB1-


In effect what I am is, does these COM rules like, Identity/
Transitivity/Reflexivity apply to just the interfaces "within"
coclass?

Following is my "main" concern, please comment on this.
In my in-proc DLL, every interface(dual) has its own CoClass, and
these interfaces are being created and returned by methods of other
coclass. I have not established 'Aggregation' among these CoClasses.
One among these CoClass, one is ROOT coclass. Now I have to expose
this In-proc dll though an Out-proc sever. And, inside Out-proc
server, I have just one method, to return that root coclass of DLL,
like following,

COutProc::GetInProcServer( IRootOfDll** pVal) //This EXE
{
       CoCreateInstance(CLSID_RootOfDll,.....pVal); //This is
Dll
}
Once, caller gets pVal, he will fetch other interfaces, implemented
inside Dll. DonBox book, under Binary-Composition has similar example
and says 'Aggregation' should be used to let IRootOfDll know that it
is being used. Then I flashed to me that, to survive Marshalling,
'Aggregation' is needed not just in the above function(in EXE) but
also among the CoClasses that are inside Dll. Even if I use
'containment' and duplicate the DLL's object heirarchy inside EXE, I
may still have to bolster this containment wrapper with 'aggregation'.
These are the things that I would like to get clarified these concept
before I start implementing solution.

My another major conecern is, applying aggregation to multi-layered
"parent-child" object. I do not even know whether this is possible.

Thanks for responding.
Ramesh

On Oct 10, 9:49 pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:


erface. It is perfectly fine, and quite common, to have a


mplemented by a different object with its own distinct COM


ily a good idea. It is hard to be sure where they are going


d. -- RFC 1925