Hi Alan,

>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?

Almost. You can also cause a dangling reference by setting a property to the parent object. For instance, if you have a form manager and store references to forms in an array, you need to clean up these references, as well.

>Also, you mentioned that the Destroy event occurs too late to prevent the dangling references.

In my experience, in 99.9% it's OK to clear references in the Destroy event, but this 0.1% is causing a GPF.

>Is there an event/method that I can use to clean up any object references that may exist

No, that's what makes the topic so difficult. All you can do is to add code to your classes to detect such cases while you debug the application. For instance, you could create a cleanup method and print a debug message in the Destrox event if it hadn't been called previously. Or, you could determine a point at execution where you know that none or only certain objects should exist and validate this against the Init/Destroy log.

>perhaps bind the Destroy event to a delegate method so that the delegate method cleans up object references before the Destroy event code executes?

When VFP is ready to call the delegate it's already in the Destroy process. That would be too late, as well.

--
Christof