Nancy,

I was using FORM.AddObject and FORM.RemoveObject. I think The CreateObject() approach requires THISFORM.oRef=.NULL., but usually I release them (THISFORM.oRef.Release) before releasing the form. There was particular case with toolbars (which does not have a native Release method). One UT member susggested the use of UDF Release with THIS.Release in it.

If you do not release the oRef prior to form exit, and if the form has a Private DS, then the DS does not release properly, as I found out.

The AO/RO approach had problems with grids. RO didn't come up clean before AO is executed, so I got a "Object with same name already exist" message. It releases OK when all the code in the Valid had finished executing.

>David Frankenbach uploaded a utility called "ObjRef-finds dangling object references" that may help. Please let me know if you can't find the file.
>
Checking it now ... Thanks.




>>Back to the original Q. Is there a way to make sure the Obj is "really" destroyed? I check with a poll to the THISFORM.Obj.Name. WHen it fails, I assume it's gone, but recently I tried the code chiunk again on a Valid, but it didn't work this time. Looks like the polling didn;t meet up to my expectations.
>>
>
>Generally, if you create an object and assign it to a property (say, a form property) then when you destroy the form you must set the property to .NULL.