Dragan --

Your quote about ambiguity is entirely appropriate. I did not mean to say that they get a new form if they select different columns, only if they drilled down differently.

So, how would I track memory? Is there a SYS function or something?

>>Tamar --
>>
>>Why not simply check whether a given form is already open and bring it ot the top when the user tries to open it again?
>>
>>That would make sense in a general case, but not in my case.
>>
>>In fact, all of the forms the user will be seeing are actually the same form -- each form is created from parameters passed to it from its calling form.
>>
>>For instance, the original form is usually "Summary by Class". The user might then select "Summary by Product Category for Class = Europe", etc. Each time the user "drills down" to a further level of detail, a new copy of the same form is invoked, but with different parameters.
>>
>>Furthermore, once a form is created, the user may select which columns are to appear in the report (choice of about 50 right now). (This list of columns is inherited from the calling form.)
>
>Since all your forms are of the same class, they don't take that much memory as objects, but just having so many windows floating around means that something (Windows or Fox) has to keep the bitmaps somewhere, in case some portion of a window becomes visible. That can be much more than what the object, buffers etc consume. So maybe it'd be a good idea to use some tool to track the consumption of memory as you open and close your forms.
>
>Another suggestion: if they change the column selection, why does it have to show in a new form? You're still showing the same records. Besides, the users may want to reuse the column selection - they select a set of records, then a set of columns, then drill down into subsets of these records by the same set of columns. The first step in this does not really require a new form.