Jim,

>Well, that's your opinion. I find the concept of a "working" app developing possible slowness, or even failing (and all due to memory consumption ever-rising) when subjected to significant load to be much more troublesome.
>I see them *both* as programming problems, but I feel that with the revision I propose that the difficulty you find chaotic would quickly and easily be found and corrected at development time.
>As it presently stands, I review my just debugged program to ensure that I have RELEASEs coded where needed and so package it for release. then the sh** hit the fan. Why. . . because release didn't release (nor complain) because of some dangling reference (which I don't even use any further!@#@).

>I don't know what you are getting at here. What I am saying is that RELEASE will do nothing under the right (wrong, actually) circumstances BUT it will NOT tell you so! This has to be considered bad form, no matter how you slice it.
>What I propose is to make RELEASE (and any ilk) RELIABLE - when I command RELEASE, then DO THE RELEASE, and I'll deal with the consequences.
>Pretty simple concept, actually. No chaos at all (that I didn't do to myself).

I misunderstood that you might be calling the Destroy() event method with the intent of causing the destruction of the object. Instead of it's true function of being a notification to you that the object has been destroyed and this is your last chance to clean up any object references that it holds.

This code illustrates why your wishlist item can't be realistically considered IMHO.

goServer = createobject( "oServer" )
x.oServer = goSever
y.oServer = goSever

* at this point one memvar and two object properties have a reference to the oServer object in memory.

release goServer && where you absolutely want the object totally removed even though 2 other objects hold references to it.

the chaos now ensues when either x or y try to use their server references. And the real problem is that object x may fail an hour after the release of goServer so your assertion that it's easily tracked down in the development environment is not true.

The oServer object has to remain in memory until both x and y get rid of their references. Which they would properly do inside their Destroy() methods with this.oServer = .null. They can also clear their references before that if they are done using the object.

In fact release goServer does work right now, exactly as it's supposed to. The memvar goServer is gone. If you DISP MEMO it's gone. So the command did indeed work. The object in memory is not gone because of the 2 other references to it.

I've developed very complex data structure applications that heavily use object references as link pointers. I never have a problem with dangling references because I properly code the Destroy() method removing the link references by setting them .null.

>Someone mentioned that this had lots to do with reference counts. Well, that likely is so, but that doesn't make the current behaviour acceptable. And, in fact, the "problem" regarding reference counts may have more to do with bad VFP design. If, for instance, it is relying on a WIN functionality to maintain reference counts, then maybe what is really required is for VFP to maintain its OWN reference counts in addition to letting WIN keep counts.

Object reference counts have nothing to do with Windows itself. Reference counts are a big plus in VFP. C++ doesn't natively have object reference counts and it's quite possible via sloppy code to leave dangling references which are just waiting to cause memory page faults and app crashes.

CLEAR ALL is the absolute get rid of stuff fall back in VFP

The bottom line is: If you use object references, you are responsible to clean them up. It's no different than restoring SET environments in Xbase, or releasing allocated resource handles in Windows code.