>>>>>>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!
>>
>>SET COVERAGE will only log VFP code and no internal processes.
>>
>>Have you tried to identify the problem by elimination ? Remove half of the objects and deterime whether it also cuts the time in half? If not, continue to do so until you have found the point where it significantly reduces the amount of time needed to destroy the form.
>>
>>Walter,
>
>The form(class) builds a graph based on several objects for each day in a date range. If it is a year (the current max) then it has most objects. When following the removal process it is clear that the first closed objects consume most time and that the closure time decreases rapidly. The last to be closed objects thus close very quickly.
>
>BTW, I can simply fool the user by displaying a text like 'Processing 02-02-2014' in each Destroy() of the object that has info of the day. But it's even better to remove with the speed of the addition, which takes less that 2 seconds even if it is a whole year. This addition speed is surprisingly fast because it implies a quite complex processing of a table with info about an employee's working shift times.

Did you try to use a method that removes all the objects with an explicit "RemoveObject()" call, rather than relying on native behaviour when the form is destroyed? This method would be better to monitor with set cover as you can see how much time each and every object removal takes.


Walter,