Re: IUnknown, Identity rule for 'nested objects'
In effect what I am is, does these COM rules like, Identity/
Transitivity/Reflexivity apply to just the interfaces "within"
coclass?
Yes.
Thanks, this clears all of my doubts, I did not know this key
information.
You may have some difficulty figuring out when that out-of-proc server is=
safe to shut down. You don't want to terminate it while
there are still outstanding references to objects inside the DLL it hosts=
.. I suppose you could check DllCanUnloadNow periodically.
My understanding is you are referring to EXE prematurely shutting
down, and to avoid that EXE should invoke DllCanUnloadNow() of
embedded dll.
At present I do not have that, and following is my current
implementation; as you can see I am not calling AddRef(). Callers of
this Out-proc is mostly C# applications.
IDL for EXE
-----------------
#import ("abc.tlb"); // this to import the DLL
interface Factory
{
CreateAbcInstance(IAbc** ppVal);
}
CExe::CreateAbcInstance( IAbc** ppVal)
{
hr = CoCreateInstance(CLSID_Abc, 0, ALL, IID_IAbc, ppVal); //
Here I am not calling AddRef(), thought that caller's Release() would
take care.
=
//
I am not sure whether I have to call AddRef() and Relase() in the end.
}
Have you tried a straightforward implementation? Did it not work for you?=
In what way did it fail?
Yes, I have a simple implementation already(as shown above). I was not
confident about what I had done because this is the first time I am
dealing with mutiple objects, wrapping dll inside another Out-proc
server. My initial implementation gave proble: 'enum' values passed-in
(from client), through IAbc member's had wrong value on their arrival
at Abc.dll. To fix this, I had to remove _MERGE_PROXY preprocessor
from both Abc.dll and EXE, and that resulted in them using using
'Universal Marshaller'. ProxyStubClsid32 = {00020424-0000-0000-
C000-000000000046} With this change things have been working. In my
IDL file, interfaces declarations are outside Library{} section, and I
do not think this has any effect because I am not using CustomProxy
anymore.
When I searched for IID of my interface I found this
{aaaa-bbbb-} default=PSFactoryBuffer'
{aaaa-bbbb-}\InprocServer32 default=C:\...\adbc.dll
I am curious what this PSFactoryBuffer' is doing.
Thanks for responding with patience,
Ramesh
On Oct 11, 10:30 am, "Igor Tandetnik" <itandet...@mvps.org> wrote:
asnowf...@gmail.com wrote:
COM identity rules are only about interface pointers returned by
QueryInterface. It is perfectly fine, and quite common, to have a
method (other than QueryInterface) on one interface return an
interface implemented by a different object with its own distinct
COM identity.
When you 'perfectly fine', are you also including the case where
Marshalling is involved?
Yes I am.
My understanding is, marshallers call QI().
Yes, they sometimes do.
Let me give an example(x.dll),
CoClass A CoClassB
{ =
{
Inteface IB1;
Interface IB2;
};
Assume a method of IA1 returns pointer to IB1 by calling
CoCreateInstance(). Then marshaller may call like this. pIB1-
QueryInterface(IID_IA!);
No. Why would it do that? What reason it has to believe that CoClassB is =
in any way related to or aware of IA?
In such case IB1 would not know about IA1.
And rightly so.
In effect what I am is, does these COM rules like, Identity/
Transitivity/Reflexivity apply to just the interfaces "within"
coclass?
Yes.
Following is my "main" concern, please comment on this.
If you insist.
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.
A perfectly reasonable arrangement, generally known as an object hierarch=
y.
I have not established 'Aggregation' among these CoClasses.
Wise decision.
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,
You may have some difficulty figuring out when that out-of-proc server is=
safe to shut down. You don't want to terminate it while
there are still outstanding references to objects inside the DLL it hosts=
.. I suppose you could check DllCanUnloadNow periodically.
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
You are not doing composition, so that chapter doesn't apply. Composition=
is a technique whereby two or more objects (either
source-level classes or binary components) cooperate to pretend to be a s=
ingle COM component (more formally, maintain a single COM
identity). Nothing in your problem statement suggests that you may need o=
r want that.
to let IRootOfDll know that it is being used.
Why does it care?
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.
In your mind, what precisely is the mechanism by which marshalling would =
"kill" your arrangement, so that steps to assure "survival"
must be taken?
Have you tried a straightforward implementation? Did it not work for you?=
In what way did it fail?
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'.
Because otherwise... ?
These are the things that I would like to get clarified these concept
before I start implementing solution.
I hope I was able to alleviate your concerns.
My another major conecern is, applying aggregation to multi-layered
"parent-child" object. I do not even know whether this is possible.
It doesn't make any sense to even try.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not necessar=
ily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly overhea=
d. -- RFC 1925