Ooops. . .

Rick,

As I typed the long message I wondered why X1 and X2 were still there ahen they had been released.

Turns out I had not (repeat: NOT) changed the actual RELEASE statement when I added the loop.@!#@$!

So PLEASE, if you decide to copy/run the code, change the release statement from "x" to "X&LC."

Doing that you will see Y1 and Y2 is the DISP MEMO, but not the X1 and X2, nor will you see "2 windows defined".. But as the book clearly states, becuase there is a "dangling reference" (not the term used in the book, but a term coined on UT I guess), the actual memory occupied by X1 and X2 is *NOT* actually released.

It is this fact that leads me to question the definition of the output of SYS(1016).

I apologize for the clumsiness.

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