Mark,

>>My concern is 'inside' a VFP app., where I might instantiate/reference who knows what, who knows when.
>
>Is this really the way your code is written? I doubt it, Jim. :)
>
>>It sure looks to me like VFP is either relying on the OS reference count or maintaining its own blindly applying the OS's "rules"
>
>I very much doubt that VFP is bothering with any Windows functionality simply to keep track of the number of clients of an object in VFP code. This really doesn't have anything to do with Windows. Reference counting to aid memory management and garbage collection is a general-purpose technique, found in a lot of programming.
>
Well, WIN *does* keep reference counts for objects instantiated on Servers by Clients (if that's a reasonable way to put it). And WIN *does* have to worry about independent clients *plus* performance for Server users generally. So it makes perfect sense that WIN itself would *NOT* release an object just because one of those clients said it was finished with it.
*IF* VFP uses those reference counts, *OR* if VFP mimics that way of handling object references internally, then I contend that this is WRONG WRONG WRONG.
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.

>>And, as said previously, (a) any command which doesn't do the full job one expects it to do ought to report back that status for further processing,
>
>It all depends on what you expect it to do, doesn't it? If your expectation is that RELEASE X should obliterate the object that X refers to, then yes, RELEASE isn't doing what you expect. If instead you realize that RELEASE X merely decrements a reference count, then there should be no surprises (nor error messages).
>
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!
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. What do you think *THEIR* expectations would be??

>>what business does it have holding on to anything I said to release (even if I did so prematurely)?
>
>You just said to decrement the reference count. That's part of the definition of the language. RELEASE is performing to spec.
>
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??

>>Just because people have found some 'straightforward coding practises to eliminate the problems this poses is no reason to further simplify the coding for everyone generally, and this is the nub of what I believe would be a GOOD REVISION.
>
>People have posted code to completely remove an object from memory. Whether this is necessary or not (i.e., solves a "problem") depends on how tightly woven your interobject relationships are. If they are tightly interwoven, you have a couple of solutions. Frankly, it doesn't sound very encapsulated to me to unconditionally remove an object from memory, since that requires knowledge of every possible client of that object. In a way, VFP better supports the "who knows what, who knows when" you mentioned above.
>
I don't know where you are getting your "client" from. If you mean a *real* server's "client", then it is the OS which has the responsibility, as outlied above. If you mean some fictitous 'client' as I may define it in my code, then it is up to me to *PROPERLY* code when an object is to be released, and if I do so prematurely, then I should pay a penalty in the form of some notification or some failure. 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). This is far far better than a memory leak which is only detected *AFTER* implementation.

>However, I agree it's sometimes necessary. The question is whether VFP's whole reference counting behavior is flawed, and I don't see any evidence that it is. Just as with my problem where focusing a grid changes the workarea, it was a design decision that weighed one factor against another, and this can cause confusion.
>
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.

>But when you realize what RELEASE X was meant to do, and what it does, the confusion goes away.

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

Cheers,

Jim N