Rick,

With a clearer head I have found that the documentation (book - VFP 5 "Developer's Guide" or VFP 6 "Programmer's Guide") is correct with regard to 'dangling references' to an object causing it to remain in memory. Note too that RELEASE gives no indication that this is the case, leaving one to presume that it functioned as expected.

The short program below exhibits, on my 64 meg Pentium 233 and with the FOR loop set to do 99 iterations (not 3 as currently coded) fails with a "There is not enough memory..." error on the 88th CreateObject. This is, I would call it, a 'memory leak' within VFP.

The run with 99 also runs REAL SLOW after the 8th or 9th CreateObject. Lots of hard-drive activity too, suggesting that SWAP is used from that point on.

A second run, typing RESUME to end the first run and changing the FOR loop to execute only 3 times, shows the starting user-object memory usage to be 44,404,408!!! The 'cost of Xx' also shows to be around 9,000 bytes as opposed to just over 500,000 in the first run.

I cannot explain this at all.

Finally, on ending VFP, the hard drive went crazily for about a minute, presumably clearing the SWAP file.

But I do feel that this proves conclusively that a 'dangling reference' *DOES* result in slowness, possibly leading to an out-of-memory condition UNDER THE RIGHT CIRCUMSTANCES.

Here's the code, again not nicely formatted for my lack of capability to do so for this medium:

clear
clear all

BaseStartMsg= "Starting user-object memory use is "
AfterXCreatedMsg= "user-object mem. right after creating form object "
CostOfXMsg= "So cost in memory of "
AfterDangleMsg= "After making a (later) dangling reference to "
CostOfYCreated= "And the memory cost of "
AfterXReleased= "Size now occupied by program after releasing "

Base_At_Start_ln= VAL(sys(1016))

? BaseStartMsg, base_at_start_ln
? " "

* Changing the FOR loop to do 99 iterations gave, on my 64meg machine,
* a "There is not enough memory to complete this operation", which was
* the "this.Tag = replicate. . ." command in cForm.Init, after the 87th Xx object
* was created (ie on the 88th object) [ VFP 6.0 in virgin state ]

* CURIOSITY: A second run of the program (after changing the loop to run 3 times
* and executed right after completion of the first run after resume of
* SUSPEND) runs OK but has the following anomolies:
* a) Starting user-object memory use is 44,404,408 bytes despite the
* program having a CLEAR ALL at the start;
* b) Cost of Xx shows to be around 9,000 bytes (in the first run,
* done right after starting VFP, it averaged 500,000+ bytes).
* TO ME THIS LEADS TO SERIOUS QUESTIONS AS TO JUST WHAT SYS(1016) REPORTS.

FOR LL = 1 to 03 step 1

LC=ltrim(str(LL,2,0))

Size_at_start_of_loop_ln= val(sys(1016))

x&LC. = createobject( "cForm" )

Right_After_X&LC._Created_ln= val(sys(1016))

Cost_of_X&LC._ln= ;
Right_After_X&LC._Created_ln - Size_at_start_of_loop_ln

? AfterXCreatedMsg + "X&LC.", VAL(sys(1016))
? CostOfXMsg + "X&LC.", Cost_of_X&LC._ln

y&LC.= x&LC..txtBox

After_Y&LC._referencing_X&LC._ln= val(sys(1016))

Cost_of_Y&LC._ln= ;
After_Y&LC._referencing_X&LC._ln - Right_After_X&LC._Created_ln

? AfterDangleMsg + "X&LC.", val(sys(1016))
? CostOfYCreated + "Y&LC.", Cost_of_Y&LC._ln

release x&LC.

After_X&LC._is_Released_ln= val(sys(1016))

? "Memory cost of Y&LC. after X&LC. released", ;
after_X&LC._is_released_ln - After_Y&LC._referencing_X&LC._ln
? " "
? AfterXReleased + "X&LC.", ;
after_X&LC._is_released_ln - base_at_start_ln
? " "

ENDFOR

suspend && On this SUSPEND, do a DISP MEMO in Command Window

CLEAR CLASS cForm && attempt to address 2nd run anomolies
CLEAR PROGRAM && attempt to address 2nd run anomolies

define class cForm as Form

ADD OBJECT txtBOX AS TEXTBOX

procedure Init
this.Tag = replicate( "abcde", 100000 )
this.Visible = .F.
endproc

enddefine

Cheers,

Jim N