Excuse me. I see events as simply virtual functions/methods that are called by VFP. I have put object member variable destruction code in my destroy() events, but this isn't getting executed(there must be another object reference around somewhere). Is there any way to debug to see where each of my object references are? I have narrowed down the problem to this code:

This.oMover.oSourceItemList = This

"This" has a reference back to oMover as well. If this code isn't executed, my form closes properly. oMover's destroy event sets oSourceItemList to .NULL., and "This"'s destroy event sets it's object reference to oMover to .NULL. in it's destroy event... I think it's something to do with this reciprical referencing, but the debugger doesn't show me destruction coding as VC++'s debugger does(really helpful for situations like these)... Thanks.



>Destroy() is an Event, not a method. It is called when object is destroyed. It does nothing when called explicitly.
>
>When you have any object references on the form (like you described), you have to clear them in Release method and in QueryUnload event, in other words, BEFORE VFP attempts to close the form by real destroying objects.
>
>HTH.
>
>>Hello. Does anyone know what the default destroy() functionality really does? Does it go through properties and change object references to NULL, decrementing the object's reference counter so it can REALLY be destroyed when this reference count goes to zero?
>>
>> I ask this, because I'm having a weird problem with a form not closing. I have an object with a member variable/property. I assign an object instance(one of the controls on the form) to this during the execution of my code(it's .NULL. by default). When the form is released, if this property is not .NULL., the form doesn't close-- the "X" button goes gray, and the form hangs there(I tried a command button calling thisform.release() as well-- same results). If the property is .NULL., the form closes with no problems... I'm not sure if it matters, but the object instance that this property is set to also has a pointer to it(yes, this is required)...
>>
>> Anyways, any thoughts would be appreciated... Thanks.