>>>myObject.release
>>>myObject="X"
>>
>>I don't understand your suggestion. Would you please explain?
>>
>>Thanks.
>
>I looked through a project I [thought] would have a sample I could illustrate with - but it must have been another one!
>
>I remember doing it in a project that was almost all PRG classes. Some of the "housekeeping" routines made decisions based on whether or not some of the bject references returned
VARTYPE(someObjectName)==[O]
.
>
>And I do remember being annoyed when objects "I knew" had been released [still] returned a
VARTYPE
as an [O]bject.
>
>I tried all sorts of things, like:
>
DO WHILE VARTYPE(someObjectName)==[O]
>someObjectName.RELEASE
>ENDDO
>
>Pretty clumsy, right? Since I knew I had released the object, I suspected it was a timing issue with VFP (PRG projects seem to clock a little faster). So, in that case, assigning the object a 'character type' assured my 'housekeeper' would not confuse it with an object.
>
>Another issue I bumped into was that releasing a child-object, 'inside' the child was also unpredictable. I found that 'setting focus' to, or 'activating' the parent (or container object) and then releasing the 'child' (from it's parent) gave predictable results.
>
>In summary - for timing issues - changing the objects type resolved the problem. For child.release issues, it seems better to have the parent release the child, rather than having the child release itself.
I'm thinking, that object's Destroy method should loop through all its properties and check if it's an object. It it is, it should set it to null. This way we will release dangling references.
However, in my case the Destroy method was not called. Could it be like that:
in object's life-time we create an object with CreateObject('someManagerobject'). Then we add a reference to this to that manager object. Now, how are we going to release the original object? I don't see a way.
If it's not broken, fix it until it is.
My Blog