>>Ed,
>>
>>consider the following with my best Bill Nye voice
>>
>>z1 = createobject( "form" )
>>z1.Show()
>>z2 = z1 && create a second reference to the one object
>>z1 = .null. && the form can't destroy because another ref exists
>>z2 = .null. && now the form goes away
>>
>>The issue is with multiple pointers to the same object, the object can't go away until all references are gone.
>>
>>>I've encountered this suggestion before, assigning NULL to an object pointer, but I've never really understood why. If the object is already gone, isn't the pointer already NULL? If it didn't destroy like it should, then am I not orphaning a piece of memory that will eventually make its way to the global OS heap and float around there until the machine is turned off?
>>>
>>>Regarding the objects themselves, I don't believe they are involved in a recursive call or cyclic relationship? In fact, the label object just 'is'...there is no code attached to it at all.
>
>David,
>
>I tried it, and your point is understood. Thanks!
>
>Now, I've got a different puzzle for you. Try the code out below, running it 'as is' first. Then, uncomment section B and try it again. Next, uncomment section A and try it. Finally, uncomment section C and try it. Section B doesn't cause a memory leak, but sections A and C do.
>
>Note: This is in VFP 5.00.00.0402. I thought I had implemented SP3, but evidently not. I'm going to retry this exercise after applying the service pack.
>
>Ed
>
>
>PUBLIC lnI
>LOCAL loObject1, lnJ, loObject2
>
>* DEBUG
>* SUSPEND
>
>CLEAR
>
>? "Start: " + SYS(1016)
>FOR lnI = 1 TO 100
> loObject1 = CREATEOBJECT("cForm")
>*-- Section A (Note that it's a TextBox)
>* loObject1.AddObject("nTemp2","TextBox")
>
> loObject1.show
>
>*-- Section B
>* FOR lnJ = 1 TO 100
>* loObject2 = CREATEOBJECT("custom")
>* loObject2 = .NULL.
>* ENDFOR
>
> loObject1 = .NULL.
> IF (lnI % 10) = 0
> ? STR(lnI) + " " + SYS(1016)
> ENDIF
>ENDFOR
>
>? "End: " + SYS(1016)
>
>DEFINE CLASS cForm AS Form
>*-- Section C (Note -- cTextBox)
>* ADD OBJECT nTemp AS cTextBox ;
>* WITH Top = 40
>
> PROCEDURE Unload
> ? "Unloading"
> ENDPROC
>ENDDEFINE
>
>DEFINE CLASS cTextBox AS TextBox
> PROCEDURE Init
> THIS.Value = lnI
> ENDPROC
>ENDDEFINE

David,

Perhaps I am on the wrong track, if you could set me right. When I check for the existence of an object, I normally do something like this;

IF TYPE("oMyObject") = = "O" AND !ISNULL(oMyObject)
*-- Object exists
ELSE
*-- Object does not exist
ENDIF

This to me means that there will be a condition where oMyObject's type is in fact 'O' , but it is a NULL. And, if we try and access 'oMyObject', VFP will return an error. I assume that there is a distinction between the object type and what's there at the end of the pointer (in C++ parlance it would be something similar to
*oMyObject, which in the latter case will be NULL). This leads me to believe that the var type is definitely 'O', however, at the end of the reference pointer the memory has been set to NULL (or CHR(0) maybe).

Please comment.