>>>>>>>>>>>>>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.
>>>>>>
>>>>>>Yep, see my first message. Using removeobject() improved performance. Native: 55s, my code 25s. However, I removed only some of the objects. My later test drilled down and did a remove starting at the 'youngest' (child) level and ending at the nearly 'oldest' (parent) level. It resulted in 55s. I might try to do the collection phase (which takes a significant part of the processing time) at the init phase....
>>>>>
>>>>>I just did a test with a form, creating 2000 textboxes and removing them upon demand. On my (modest) laptop, it took approx. 1 second to destroy the form. Can you tell us a bit more on what object, how many references and the object hierarchy?
>>>>
>>>>

It has 
>>>>  a pageframe 
>>>>   with a page. 
>>>>     On that page it has one container 
>>>>       that has four containers. 
>>>>          The first and second container contain an ole slider. 
>>>>          The third container contains createobject'ed containers 
>>>>              that contain a shape (for the hour caption). 
>>>>          The fourth container is the most complex one. It contains createbject'ed 
>>>>             day-containers, 
>>>>             daycaption-containers, 
>>>>             shift-containers, 
>>>>             workpart-containers, 
>>>>             nonworkpart-containers (pz=partieel ziek) 
>>>>             and hour-line objects. 
>>>>                 Some of them have properties with object references to certain other containers.

>>>>
>>>>Can you follow my explanation? :)
>>>>
>>>>Anyway, for each day creatobject() is called, let me see..., 7 times. So, 365 days is 7x365 is 2555 new objects each containing two shapes or a label or being a line.
>>>
>>>ok, I see that the number of objects is far larger... so more closer to 10.000. I did a little test and can confirm that even in VFP9 this is a problem. 10.000 objects will take about 40 seconds to destroy on my laptop while 2000 only one second.
>>>
>>>I do think that the problem you are experiencing is due to the way VFP references the object in the destroy process and that there would be no easy way out. Perhaps you can find a workaround by issuing less objects by drawing (lines, shapes and text) into a container instead of putting objects in there.
>>>
>>>More dramatic is to draw the whole thing with GDI+ .
>>
>>First I have to make one important correction. I don't use CREATEOBJECT() but ADDOBJECT(). Having said that, I tested NEWOBJECT() but it was similar.
>>
>>About your finding and tip: I think I can do with less objects indeed. For example, I built that container that only contains a line. An ADDOBJECT() of the line will be faster destroyed because it doesn't need to also destroy the inner line object. Furthermore, I now use one object for each hour line. Perhaps I can simply draw those lines. I'll see. Thanks for the advice.
>>
>>UPDATE - I have disabled the addobject code for two of the seven above mentioned. The 7x365 gave around 5970 destroys. It'll now be around 4260 destroys. The original 47 seconds became 14 seconds. And when doing a removeobject() via an explicit loop this became 7 seconds.
>>
>>My hunch is that there is a certain amount of workspace that is extended if the number of objects becomes too large and that will cause a slower destroy. The lesson: VFP can handle many objects, but if there are very many then destruction will slow down.
>>
>>Perhaps there's some type of memory that could be increased?!
>
>Have you mdotted your code - especially if you have tables open?

All my code is m.dotted. :)