James,

The point was to try to show Rick G. that he *likely* had a "dangling reference' which was causing what he observed. The code purposefully creates a dangling reference for that purpose.

For additional clarity, a "dangling reference" is a memvar coded to refer to an object BELONGING TO another object and *NOT RELEASED or CLEARED to NULL before a RELEASE of the 'owning' object is executed.

Of course there will be no problem if there are no dnagling references (when all runs properly, as testing seems to confirm).

It was, in particular, the SYS(1016) output from the second run of the code, for 3 interations only, which really puzzled me and has me questioning SYS(1016). It seemed accurate enough in the first iteration of 99 (failing on the 88th).

Cheers,

Jim N


>David,
>
>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?
>
snipped