I cannot see where the dependency is happening, but the problem must be what you are suggesting or some variant thereof. At issue in my mind is that I can find no evidence of either residual stack frames or object references pertaining to form B that would prevent its _immediate_ destruction, rather than after A is destroyed. But as Rummy says, absence of evidence is not necessarily evidence of absence, and I may just not know of some things not known even though I do know of some known unknowns.

The workaround I'm using is pretty simple: Extract that code dependent on the back-reference to form A, and put that code into its own form-based method. Set a form-based flag to indicate/control that it runs only once. Call the method from both the the Click() of the cancel, as well as from the destroy. The call from the destroy event so that cleanup occurs whenever user closes the form via the closebox or VFP exit.

>Mark,
>
>An object can not destruct while one of its or one of its contained objects methods is on the call stack. You should get out of the habit of doing things like calling the Click() method of an internal object. You should instead call a form level method from both the cmdCancel.Click() and from the outside object. If you are holding object references like this you should always check to make sure it's still a valid reference before attempting to use it.
>
>You might consider using a Register()/Unregister() method so that the two forms can tell each other that they are shutting down.
>
>>I'm stumped. Why is this happening?
>>- Click() method of cancel button on modeless form A is invoked.
>>- Form A's cancel routine checks for existence of a modeless child form B that form A might have created earlier. If B exists, then A invokes the Click() method for B's cancel button, and B releases itself. Also, if B exists, it holds an object reference back to form A (as a form property initialized in B's INIT)
>>- B's cancel routine returns as expected to A's calling code. Then A releases itself. B has already released itself. In B's destroy event, it tries to access the object reference to A.
>>
>>Result: Error. The reference to Form A is no longer valid. Form A's destroy event has fired before B's. This seems odd to me. Along the timeline, the "inner" cancel operation is that of form B, yet the first destroy event to occur is that of form A.
>>
>>Keep in mind I'm talking about separate and equal modeless forms. There is no containerization here as with controls on a form.
>>
>>I would instead expect the following:
>>- Form A calls B's cancel method
>>- Form B releases itself in this method and B's DESTROY is called
>>- Form B's DESTROY completes and since form A is still around, the object reference to A is still valid.
>>- Form A releases itself
>>- Form A's DESTROY occurs
>>
>>But I have proven (to myself anyway) that such is not the case. DESTROY events for a collection of modeless forms do not seem serialized to the order of execution of the corresponding RELEASE method within each form.