Thanks for that explanation. And, if I understand you right, the only way to create a dangling reference, then, is if I explicitly set a memory variable or property to an object that is contained within a parent object/container. And then, I release the container without resetting the memory variable or property to .null. Is this correct?

Also, you mentioned that the Destroy event occurs too late to prevent the dangling references. I have used the Destroy event to set .null. to any properties that evaluate to an object. I can't rely on the Release method being called. Is there an event/method that I can use to clean up any object references that may exist - perhaps bind the Destroy event to a delegate method so that the delegate method cleans up object references before the Destroy event code executes?

>Hi Alan,
>
>>Can you (or anyone else) help me identify situations that may cause the dangling reference?
>
>Dangling references occur if at the time when VFP releases an object there's even a single reference to the object with two exceptions:
>
>- If you added an object with AddObject(), ADD OBJECT or by dragging it into a visual class, the parent class obviously has a reference to the contained object just like this object can access the parent via the This.Parent reference.
>
>- If the object is the one you created with CREATEOBJECT() or DO FORM, there can be any number of reference to the object in local, private or public variables. This refers to the object only, not to any contained object. For example, if you create a container with a label, you can have references to the container, but never to the label.
>
>Time of releasing an object is when the last variable that refered to the object went out of scope or the default behavior of the Release or RemoveObject method is executed. The Destroy event is already to late to prevent dangling references.
>
>The second reason for dangling references is when you refer to an object before it exists. In VFP this is possible due to the class object. Any code in the Init event that uses THIS.PARENT or accesses any object that is not below itself in the containership hierarchy can cause dangling references.
>
>>Your method of discovering which objects are not being released is a good idea - I will try something similar.
>
>It's actually a very good idea. So far, 99% of all dangling reference bugs I found also caused at least one Destroy event not to fire when it should. Keeping track of all Init and Destroy events and comparing that list against objects that should exist at any point in the program is a hard but good way to discover dangling references.
>
>A third reason of causing dangling references are bugs in VFP, like the PEMSTATUS() bug we had in so many versions. But those bugs get less and less with each version of VFP.
>
>--
>Christof