ILayerList::QueryLayer(int32 n)

[Guest]

Hello,

I have a question about a certain function in the SDK. In the SDK documentation of ILayerList class, it is written :

virtual IDocumentLayer* QueryLayer(int32 n) const [pure virtual]

Return the n'th layer in this document.

Caller is responsible for calling Release().

Should I not use

InterfacePtr<IDocumentLayer> docLayer(myList->QueryLayer(n));

or

IDocumentLayer* docLayer = myList->QueryLayer(n);

...

docLayer->Release();

?

[Peter Schuelke · Accepted solution]

Hello David,

both of your samples are correct. The first will implicitely do a docLayer->Release() upon destruction of docLayer from instantiation with InterfacePtr<IDocumentLayer> docLayer(myList->QueryLayer(n));

In your second sample this is done explicitely.

Generally prefer the first solution, as you can not forget to call docLayer->Release();

HTH, Peter

[Manan Joshi]

I would also like to add that always make sure that you never use the UseDefaulIID() with methods with name like QueryXXX.

As these methods generally return the pointer by incrementing its reference count and using UseDefaulIID() increases it further by one, thus creating a boss leak as release is called just once.

So using

InterfacePtr<IDocumentLayer> docLayer(myList->QueryLayer(n), UseDefaultIID());     //Boss leak

would increase reference count by one, but will call release just once thus creating a boss leak.

Manan Joshi

http://www.metadesignsolutions.com

[Guest]

Thank you to both, especially Manan Joshi. It hinted me for another problem : It seems that you should avoid everywhere UseDefaultIID().

For instance, InterfacePtr<IHierarchy> hierarchy(myUIDRef, UseDefaultIID()); should be replaced by InterfacePtr<IHierarchy> hierarchy(myUIDRef, IID_IHIERARCHY);

It seems that the avoidance of UseDefaultIID() solved my principal problem

[Manan Joshi]

Hi David,

You did not get my explanation to the full extent. Using UseDefaultIID() or the IID itself in the InterfacePtr constructor are not different as far as the increment of the reference count goes. Both these forms increases the reference count by 1.

InterfacePtr<IHierarchy> hierarchy(myUIDRef, UseDefaultIID());           //Increments the reference count by 1

InterfacePtr<IHierarchy> hierarchy(myUIDRef, IID_IHIERARCHY);        //This also increments the reference count by 1

We have to use the second form(the IID directly) in the following two cases

1. When the interface required does not have the kDefaultIID enum defined.

2. When you have multiple implementations for the same interface on the boss class.

So replacing the UseDefaultIID() with IID won't solve the problem if you are getting the boss leaks from the InterfacePtr construction statements.

The point is that you should use the following contructor, in case where you get a reference incremented pointer Like in case of the methods that start with the name Query.

InterfacePtr::InterfacePtr(iFace * p)

I hope this makes it clear.

Manan Joshi

www.metadesignsolutions.com

[Guest]

I understood well that when you construct a copy from a Query(), you don't need the interface ID. That's what I have always followed actually.

I don't know why, and I may sound stupid saying this, but my problem of hang in CS5 seems to be solved with the avoidance of UseDefaultIID(). I use the same code without any problem in CS4.

[Manan Joshi]

My explanation was only to clarify that replacing the UseDefaultIID() with the IID won't change anything w.r.t the reference count imbalance problem, they both have the same effect. If there was a boss leak when using UseDefaultIID() then it won't get rectified by using the IID.

Manan Joshi

www.metadesignsolutions.com