>Well, WIN *does* keep reference counts for objects instantiated on Servers by Clients (if that's a reasonable way to put it).
Oh, sure. Windows does plenty of reference counting. But it's such a simple concept that it wouldn't make sense for VFP to ask Windows to do its bookkeeping for it.

>*OR* if VFP mimics that way of handling object references internally, then I contend that this is WRONG WRONG WRONG.

Reference counting is a general-purpose technique. There'd be no need to "mimic" Windows to provide it. It's the core of garbage collection.

>The OS has system-wide responsibilities, while any VFP app. has only app responsibilities. It is not proper that VFP treats my app as if it has system-wide responsibilities - it should do what I tell it to and let me face the consequences.

If that's what you'd really like, then I'd suggest C++ (seriously). But even in C++, the string class does reference counting, and it has no system-wide responsibilities. This just isn't an OS issue.

>Have you bothered to read ther VFP 6 (or 5 for that matter) Help for RELEASE, RELEASE ALL the Release method or the Destroy event? It sure looks/sounds like you haven't, because had you done so you would know that the concept of reference counts is *never* mentioned. Furthermore it explicitly states, for all of them, that the thing being released is removed from memory!

Well, what are you going to trust, the documentation or the way it actually works? My goodness, if we nattered on about all the faults in the VFP documentation, we'd be here forever.

>I know a little differently from additional reading and from experience, but what about the novice who is just starting (and keep in mind that, unlike you and I, most movices do *not* use the WEB to look for Help or knowledgebases or anything - they use the books and the Help and try to code.

Any programmer who tries to learn like that in this day and age is not going to remain in the field for long.

What do you think *THEIR* expectations would be??

I think they would agree with yours. And they would learn differently, once they got into a situation where it was necessary. After all, intricate object dependencies are not common in novice code (or at least they shouldn't be).

>See above. *NOT* at all to "spec". Though I will have to admit that very little of the actual "specs" are to be found in the documentation - only in KB articles where a problem is reported and then we are told what the spec is. Remember the phrase "performing as designed" and how often that is the response??

The thing is, Jim, the way RELEASE works makes good sense to at least some of us. And there's no way that MS designed this behavior by accident. That's what I mean by "to spec." It's not the same as "as documented." :)

>I don't know where you are getting your "client" from.

A client is something that requests services from something else. In this case, the clients are all the variables and properties that point to the object you want to RELEASE, but can't.

>Of course I, in *my* program, *will* have full knowledge of every 'client'. Should I err and release before all of my 'clients' are done with an object, let me fail (it is my fault, after all).

But you said before that object are created "who knows when and who knows where". Which is it?

>This is far far better than a memory leak which is only detected *AFTER* implementation.

What memory leak?

>I think you give VFP designers too much credit. It is far more likely, from the (paltry) evidence available, that they simple mimicked Win and/or VB behaviour and gave this very little thought.

Only to someone who's not really familiar with garbage collection, a technique that has been around for decades.

>See above again - nowhere in Help am I told what you believe and what I have come to learn!

If you trusted Help to tell you everything you need to know to program VFP, you wouldn't be where you are today.