Rick,

Jim's code doesn't duplicate a memory leak problem at all. If you can create a test code fragment that really, truly shows a memory leak the VFP team would love to see it so it can be fixed. How many thousands of objects are you creating in your app? I just ran this version of code I posted earlier:

clear all
activate window "debug output"

for i = 1 to 1000
   x = createobject( "cForm" )
   x = .null.
endfor

define class cForm as Form

procedure Init
this.Tag = replicate( "abcde", 100000 )
this.Visible = .t.
debugout program() + " " + sys(1016)
endproc

procedure Destroy
debugout program() + " " + sys(1016)
endproc

enddefine

Other than the couple of minutes it took to run, with no visibly apparent slowdown between iterations the different between sys(1016) at the start and end was only 7408.

If your app shows a steadily increasing memory use I'd strongly suspect that you have object references that are preventing proper object destruction.

>Wow! Sounds like while I was out "trick-or-treating" last night you were busy with that coffee pot. Thanks for all your valuable input. Essentially you have gone through the same iteration that I did when I first discovered my app slowing down. First I put SYS(1016) calculations throughout my code and then step by step removed CREATEOBJECT() or AddObject(). You are correct that SYS(1016) reports can be volatile -- but there is an unmistakeable diminuation of available memory as objects are created and released. As I said earlier, I have "solved" the problem by reuseing objects -- sort of like reuesing records in a .DBF. SYS(1016) is still moving up and down (at least there is downward movement) and available memory is much more consistent now.
>
>Again, thanks. I need to study all your messages and code more carefully, but it helps my sanity if nothing else to see someone else has replicated the problem.
>
>Rick Grinter