Rick,

**IGNORE** ALL MY PREVIOUS on this topic - now I am really confused!

I kept 'playing' with that code and noticed that, quite possibly, the "dangling reference' that I was using in it was *NOT* a genuine "dangling reference".

So I created one modelled on the book's content it does not name a property, it just names an object in the form.

The result was a DISP MEMO with *NO* Xx or Yy variables showing on a DISP MEMO.

As I wrote earlier, the book clearly states that a dangling reference will *NOT* actually release the memory occupied by an object which has a reference outstanding. So the observation here could be:

1) An error in the documentation ((book);
2) An inadequate description in the documentation (book)of what happens. For ----instance, *IF* it also mentioned that they will disappear on a DISP MEMO, ---- even though not wiped from storage, then we could possibly trust the docs;
3) An inadequate description of just what, precisely, is returned by ----------- SYS(1016).

Since there is no way to tell which of these it is, if any, I guess I have to assume a documentation error, EVEN THOUGH there have been countless queries here as to why a Form (or object) doesn't get released properly and the response is always 'look for a dangling reference' and persons often respond that that did the trick. It follows in my mind that since it can happen there, a muchly repeated CREATEOBJECT-with -later-dangling-reference could lead to a memory leak.

Maybe I should be happy that I'm learning VB.

Jim N



>>Rick,
>>
>>In the instance you cite below it may simply be that you are checking too quickly - I wouldn't be surtprised if VFP only does actual cleanup on an intermittent basis.
>>
>I did notice that the memory used did decline a bit after querying it a couple of times with SYS(1016), but it never did recover all the memory used.
>
>>But as for your real problem, are you quite certain that you don't have *any* "dangling references" to the object???
>
>At first I thought I did. But the "experiment" I tried was from the command window. I simply created an object, and then either removed the object, released the object, or set the object reference to null. In each case SYS(1016) reported a significant reduction in available memory.
>
>In the end, I have "solved" the problem by not dynamically creating and releasing objects in my application. Instead, at startup I create all of the object instances I need and simply "recycle" them. I don't think this was the intent of MS, however. BTW you're right about my misuse of the term "memory leak" since the memory is recovered when my VFP app is exited.
>
>Thanks
>
>Rick Grinter
>
>>In case you are unfamiliar with the term, it basically means some memvar containing the object's reference which has *NOT BEEN SET TO NULL* before the RELEASE (or Destroy). That will definitely cause a memory leak in you situation (though some would reject that terminology, reserving it for leaks which generally affect the whole machine).
>>
>>Good Luck,
>>
>>Jim N
>>
>>>>>Has anyone noticed that there is no way of totally freeing up memory after instantiating a class then removing it? I have a system which receives data over a telephone network. In a "good" day I may receive over 10000 events. In the 'old' days (FP2.x) I would use numerous memvars and save events to files. Now I instantiate an object and populate properties of the object before storing interpreted results. Problem is every time I CREATEOBJECT() or AddObject() I loose memory according to SYS(1016). Soon my app slows to a crawl. I am, BTW removing the object RemoveObject() or releasing the reference to it.
>>>>>
>>>>>The only way I have been able to get around this is to create the needed objects at the outset of the app and simply reuse them every time I get a new message.
>>>>>
>>>>>Is this correct? Even from the command window if you CREATEOBJECT() and then release the reference, you can see memory creeping away. The only way to get it back is with a CLEAR ALL.
>>>>>
>>>>>Any thoughts?
>>>>>
>>>>>Rick Grinter
>>>>
>>>>
>>>>Have you tried RELEASE MyClassInstance?
>>>Craig:
>>>
>>>Thanks for the response. I have not only tried RELEASE but when my objects are contained by another I have tried RemoveObject. Try the following from the command window:
>>>
>>>SET CLASSLIB TO MyClassLib
>>>? SYS(1016)
>>>MyClassInstance = CREATEOBJECT('MyClassDef')
>>>? SYS(1016)
>>>RELEASE MyClassInstance
>>>? SYS(1016)
>>>
>>>The results I just now got to the SYS(1016) query were:
>>>
>>>334820
>>>346244
>>>344988
>>>
>>>and this from the command window. When I took my application and commented out all but the creation and release of the objects and printed the SYS(1016) to the screen after each pass, my memory useage continued to creep up in approximately 12000 byte increments.
>>>
>>>Rick Grinter