>For each AddObject, a RemoveObject must be called. You don't need to do this explicitly, VFP will do it. For objects created with CreateObject: you can destroy them in several ways, but the best one is to break all links to that object (VFP will destroy the object then).
>
>If you have bidirectional ownership relations A <-> B, it's better to break both links. Basically, for each has-a relation you create, you must take care to break it too. VFP will often fail to release objects simply because there are other still valid references to them. Bidirectional links (or more generic, circuit links) are a sure source of problems if they are not treated correctly/carefully.
>
>My advice: review your design and look for a solution without such links... if possible. I don't want to say that your solution is not good. It may be the best one for your problem. But you must be careful and it may mean more effort than necessary (especially because the bugs you may encounter are usually very difficult).
>
>Vlad
>
>>1. If I use RemoveObject in the outside parent container and remove the contained objects, is the memory freed up. In other words, does Fox do the garbage collection on the CREATE(D)OBJECTS.
>
>Yes, as long there are no more references to those objects.
>
>>2. Do I have to break the backlinks before I can release objects.
>
>Yes.
>
>>3. What is the essential difference between RemoveObject and Release.
>
>RemoveObject removes objects from containers, objects that were created using AddObject. RELEASE destroys variables. If a variable holds a reference to an object and there are no other references to that object, the object is destroyed when you RELEASE the variable.
>
>>This is a thorny issue. If you play with this stuff it quickly yields inconclusive results. Except of course, if you do break rules, eventually the app crashes.
>
>Right. :)
>
>Vlad

Thanks guys. I understand that a child knows its parent and vice versa in an add-remove object scenario. Vlad your advice to always ensure there is a remove for and add is a good one. I understand that Fox takes care of those links when the parent is released.

I agree that circuit links are tricky. In my case I need them so I'll have to be real careful. A classic case of circuit links is a double linked list.

Well the problem I was having was just as you've hinted, a reference to an object that was not released. Soon as you try to close a form and it won't go away you get suspicious :)

I found that my problems centered on 3 issues. Every day ya learn something. First, I was sloppy in not declaring my variables local. I figured a variable in a method WAS local. The watch window proved me wrong. Second, I was unwittin gly creating copies of objects by using a construct such as:
FOR EACH oCONTROL IN THIS.CONTROLS
ENDFOR
so I changed it to less elegant:
FOR i = 1 TO THIS.CONTROLCOUNT
ENDFOR
Last, as you said Vlad they're tricky, a couple of typos and the objects were remaining in scope.
Thanks guys. I was near the point of giving up when I decided to REALLY look what info the debugger was giving me.
Stephen