I would suspect you might be holding on to a reference to B in A or elsewhere, so B's Destroy doesn't fire until the referring variable/property is destroyed. Set all references to B explicity to .null. as soon as possible after, if not before, calling B's Cancel.

...Jim

>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.
>
>Why is this? And what is the best workaround?
>
>Thanks!