David:

Thank you again for your responses. I had originally assumed that reassigning x or .null."ing" it out would destroy any contained objects, but when I was loosing all this memory with each pass through I tried everything. It is possible that I did do something like y = x.oSomething, but y would have been in a lower level and lost when I returned to the main application level.

We also discovered the problem with the VFP5 .TLB and also use InvokeHelper(). The VC++ program basically instantiates the VFP Server and executes a couple of methods in it. The VC++ client handles telephone traffic, modem communications, and passes information received to the VFP Server. VFP Server accesses tables, manipulates data, and basically returns BOOL back to VC++. The only reference VC++ client has is to the server object. I will continue to look at this -- I must have done something so stupid that I can't even see it, but it permeated all of my COM servers, so at least I am consistently stupid. Reuseing the objects, as I said earlier, solved the problem.

Rick Grinter
>Rick,
>
>Anytime you AddObject() the added thing will normally get automatically removed when the container it was added to is destroyed. An external reference to the object added though will prevent the container from destructing:
>
>x = createobejct( "myobejct" )
>x.AddObject( "oSomething", "Something" )
>y = x.oSomething
>x = .null. && or x = '' or x = .f. any reassignment of x would destruct it
>
>except that y holds a reference to a contained object of x so the object itself won't destruct, x will null out properly though. The object won't finish destructing until you:
>
>y = .null.
>
>One of the COM servers I've written in VFP is instantiated and called from a VC++ program. It's possible your memory leak is there in the VC++ to VFP code. We are using the Class Wizard to import the .TLB, but modifying the generated VC++ code because the VFP5 .TLBs are basically wrong (they work fine in VFP6). We call the VFP methods using the InvokeHelper() function.
>
>>This is really crazy. I tried your sample and it worked exactly as you say it does. NO MEMORY LOSS. I then mess with it a bit to make it more like the app I have trouble with. 1) I create a custom class from my class library and then .null. it out. Still NO MEMORY LOSS. 2) Then I AddObject() to the custom class, RemoveObject() and set custom class to .null. STILL NO MEMORY LOSS. 3) Now I really try to break it. I do some of the things that I originally thought left me with dangling references -- :
>>
>>x=CREATEOBJECT('myObject')
>>x.AddObject('oSomething','Something')
>>x=.null.
>>
>>NO MEMORY LOSS
>>
>>x=CREATEOBJECT('myObject')
>>x.AddObject('oSomething','Something')
>>x=''
>>
>>NO MEMORY LOSS.
>>
>>I have not tried yet to play around with method calls from within these objects, but I SWEAR there are no dangling object references in there. The other thing that is a bit different is that my app is a COM object instantiated from another application written in VC++.