James,

I think the observable fact that sys(1016) doesn't continuously increase by the size of the object as objects are created and destroyed is evidence enough the VFP is managing it's memory allocation pool and recovering memory as it needs it. For example the first cform sucks up 500k, when it's released sys(1016) doesn't show that 500k being deallocated, but when the second cform is created and sys(1016) doesn't show an increase memory use to 1m the first 500k must have been reused. Right?

You may be able to use sysmeter and track memory allocation as far as the OS is concerned. Some of the other tools from VS may be handy, but this has never been enough of an issue for me to be worth the effort of tracking it farther.

I may dedicate a test machine to run a loop for a few days and see how many billion object construct/destructs VFP can handle.

>Excuse me for jumping in. I have been following this thread because I tried a test using a loop to see if repeatedly creating and destroying an object would eventually use up all the memory and lock up the machine. It does not, so obviously VFP is recapturing all of the memory used at some point.
>
>But if it does not recapture it all when an object is destroyed, when is it recaptured? VFP does not, like many other languages, have a function which forces a reorganization of memory, which tends to make me nervous as a rule although, admittedly, I have experienced no problems that I am aware of.
>
>regards,
>
>JME
>
>PS: If SYS(1016) is not reliable, what is? How would one go about getting an accurate read on the available memory?