 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
The methods you use to manipulate a complex surface like a flipping chain all use surface interface pointers, and therefore they all affect the reference counts of the surfaces. Because a complex surface is really a series of single surfaces, the reference count relationships require a little more consideration. As you might expect, the IDirectDrawSurface5::GetAttachedSurfacemethod returns the surface interface for a surface attached to the current surface. It does this after incrementing the reference count of the interface being retrieved; it's up to you to release the interface when you no longer need it. The IDirectDrawSurface5::AddAttachedSurfacemethod attaches a new surface to the current one. Similarly, AddAttachedSurfaceincrements the count for the surface being attached. You would use the IDirectDrawSurface5::DeleteAttachedSurfacemethod to remove the surface from the chain and implicitly decrease its reference count.
What isn't immediately clear about these methods is that they don't affect the reference counts of the other objects that make up the complex surface. The GetAttachedSurfacemethod simply increments the reference count of the surface it's retrieving, it doesn't affect the counts of the surfaces on which it depends. (The same situation applies to an explicit call to IUnknown::AddRef.) This means that the reference count for primary surface in a complex surface can reach zero before its subordinate surfaces reach zero. When the primary surface reference count reaches zero, all other surfaces attached to it are released regardless of their current reference counts. (It's like a tree: if you cut the base, the whole thing falls. In this case, the primary surface is the base.) Attempts to access subordinate surfaces after the primary surface has been deallocated will result in memory faults.
To avoid problems, make sure that your application has released all subordinate surface references before attempting to release the primary surface. It might be helpful to track the references you application holds, only accessing subordinate surface interfaces when you're sure that you also hold a reference the primary surface.
Last updated on Tuesday, May 18, 2004