David,
>Jim,
snipped
>
>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.
>
I do contend that this example is far easier to discern in app. testing than the disappearing memory problem. I don't see either as chaos, but I sure see the present situation as much harder to determine.


>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.
>
Again, to me, this represents an even worse situation - what business does VFP have "using" an object which I intentionally (tried to) get rid of???
Do you truly believe that this is legitimate?

Maybe an alternative to my original proposal, though, would be to have the VFP editor *automatically* insert code in the referenced object's Destroy() to remove the links. Sort of, as you code a link, it automatically inserts the de-link code as needed. Not "intellisense", but 'intellirid'.

>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.
>
I suspect, based on reading I have done and also from what Rick S. had to say on this, that Win reference counts are implicated. And, personally, I think it is more appropriate to have a memory page fault or an app crash than to have the program refer in any way to something which has been eliminated (as far as the app is concerned). But, of course, VFP would have the opportunity to intercept those failures and tell us what the problem was in a considerably cleaner way.

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

Of course I agree with your bottom line. All I am saying is, if you haven't done the proper job of cleaning them up, then let there be an immediate penalty when an attempt to refer to a RELEASEd object is made. For sure, don't go allowing the use of something which I have said I want out of here!
And it *IS* different than the cases you cite, because now I tell the sucker what I want done and it blatantly ignores me. Even if it told me 'no can do' I would be far better off.

Cheers,

Jim N