David,

My responses are interspersed with your commentary. . .

>Jim,
>
>I have to first strongly disagree with your premise. Objects going out of scope from other objects that have references to them is sheer madness. It's much more chaotic than having an object not destruct because you have a dangling object reference that you forgot to properly clean up.
>

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!@#@).

>>And I must say I've never been comfortable with the concept of issuing a command, having it *appear* to have executed it function, only to find out (indirectly) that it did *NOTHING*.
>
>You can't call and event and cause it to happen. You can make a call to an overridden event method and that code will run, but the baseclass behavior underlying the real event will not happen. The clearest example is calling KeyPress, fine you can call it all you want, but that doesn't put a keystroke into the control.

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).

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.

Cheers,

Jim N