In case somebody is interested, I found the reason(s?) for the leak, even if I cannot explain it. When I built the framework used for the familiy of applications involved in the message below, I had to accomodate lots of legacy code that had been produced with one of the most atrocious frameworks I've ever seen. To do so there are many calls to PEMstatus to allow for the diversity of components. I've changed all references to PEMstatus to calls to a function called xPEMstatus (brilliant and original name, isn't it?) that is simply as follows:

function xPEMStatus
lparameters _obj,_pem,_attr
local _retval
_retval = PEMStatus(_obj,_pem,_attr)
_obj = .null.
release _obj,_pem,_attr
return _retVal

It sounds crazy but, not calling directly PEMstatus from within a form, solved part of the problem. I knew that this function gave problems but certainly didn'r expect them to be this bad. BTW, nowhre I have more than a single call to PEMstatus in a single instruction: if I need to test more than one PEM I use different IFs for each one.

Just changing every single reference from PEMstatus to xPEMstatus solved the problem in simple forms but the applications involved have some very complex ones. To speed up thiese forms many tab pages are left empty and initialized, using .AddObject(...) in the .Activate event of the pages. Well, the objects so added have to be manually removed. I added a RemoveObject to each Destroy event in the pages so initialized and the problem disappeared.

I haven't done extensive testing yet, I needed a solution fast, but I am not happy with my findings: they don't sound right. Has anybody experienced something similar before? Any comments would be most welcome.

>Using VFP 5.0 with any OS (NT/95/98), and regardless of installed memory I experience a terrible amount of memory loss when opening forms. I'll try to explain:
>
>I have added, for debugging purposes, some code at the end of the forms Init that shows, in the status bar, the time it took to open the form and the values of SYS(1016) and SYS(1011).
>
>When a form is run from the command window, the behavior is as expected: the first time the form is opened it takes longer that the successive runs (on complex forms up to 3 times as much) and the values reported by sys(1016) and sys(1011) are always the same.
>
>When the same forms are launched at runtime the time needed to open the form keeps increasing steadily and so does the memory usage. On a very complex form the value returned by sys(1016) increases by 300K after each run. Needless to say that it's only a matter of time before the whole thing crashes.
>
>Forms, reports, batch procedures are started through a macro. My menu system goe more or less like this: The menu is contained in a table that vaguely resembles VFP menus. The top menu is built from this table. For each menu selection there is a line built approx like this:
>
>

>			lSel = "oDS.DoMenuSelection('" + msucode + "')"
>			define bar mord of ("_" + alltrim(mparent)) prompt alltrim(mdes)
>			on selection bar mord of ("_" + alltrim(mparent)) &lSel			
>

>
>oDS.DoMenuSelection retrieves the data relative to the choice passed as the parameter (msucode is a unique key on the menu table) and based on this data builds a macro on a variable named lCommand. Then it's a simple DO &lCommand or simply &lCommand and the routine ends.
>
>Any reason why a system like this should cause such a memory leakage?
>
>TIA