>>>Is the form modeless? If so, you might try using BindEvents and not directly releasing the form in the close or 'X' upper left button. Use BindEvents to bind the Release and QueryUnload events after you have called the form to a custom form close handler. Also, you would pass the object that has the custom form handler to the form in the Init event as a parameter and store into a custom property. In your close button or when you want to programmically close the form, call the close form handler via RAISEEVENTS command (this way the form is not caught in a dangling object reference). In the close form handler, you would first set the form's visible property to False and then release the bindevents and finally release the form. Now the user will see the form disappear quickly but the form can 'take it's time' to destroy.
>>
>>The form is modal. In case a form is modeless and has a time consuming destruction, I'll try your suggestion.
>>
>>Here is the latest result from my attempts to speed it up. I built a recursive function that writes the full reference of all (well, most) objects to a cursor. Then the cursor is indexed descending based on the depth. Finally in a scan removeobject() is done for each of them, except for the level of the form itself. This cleanup did not improve performance at all. Instead, performance dropped back to 55 seconds. (VFP itself: 45s, my previous attempt: 25s.)
>
>hoi Peter
>
>Did you try to capture a coverage log. SET COVERAGE TO log.txt ? Then you can identify whether some unexpected code is run which is responsible for the delay?

I had already searched for problematic code inside the various destroy events. I now did a SET COVERAGE and it revealed no special time consuming place. But more interesting is that it does not show the details of the native closing process at all!