Hi Craig,

Since you are offering, will you please submit the following for me. . .

------- START of new submission
Fix the RELEASE command for OBJECT releases (and Release() method too
Current behaviour of RELEASE where OBJECT memvars are concerned

The Help for the RELEASE command of both VFP 5 and VFP 6 summarizes its function (in the header statement) as follows:

"Removes variables and arrays from memory"

Now this does not explicitly state that OBJECTs are included in the scope of the RELEASE command, but the "Developer's Guide" (VFP 5) and the "Programmer's Guide" (VFP 6) - on page 72 of each - explicitly states that the RELEASE command will clear OBJECTs from memory. Both, though, also qualify this functionality stating that if the OBJECT has a reference to an OBJECT belonging to it still in existence, then the OBJECT itself will not be released from memory until such other existing direct OBJECT references have all also been released.

Rudimentary testing confirms all of the above for OBJECTs and OBJECT references in VFP programs. However, the following was also observed in that testing:

1. The RELEASE command functions outwardly in an identical manner whether the OBJECT which was the subject of the RELEASE was actually cleared from memory or not. There is no notification of any kind if the OBJECT memory is not actually cleared.

2. The memvar containing the OBJECT reference which was the subject of the RELEASE command does, indeed, get cleared from the memvar pool, so that it is no longer programmatically accessible and it no longer appears in the output of a DISPLAY MEMORY command.

3. Of course the memvar(s) with reference(s) to an OBJECT which was the subject of the RELEASE command remain in the active memvar pool and so continue to be programmatically accessible.
It seems to be this (perceived) need to permit continued programmatic access which is the whole reason why RELEASE performs as it does on OBJECTs.

What does this all mean?

1. Once a developer fully understands this situation then he/she can adopt a coding discipline to effectively deal with the situation. Specifically, he/she can ensure that every time an OBJECT referencing memvar is initially typed into a program they will immediately skip to the Release method for the form and add a RELEASE command making its subject the memvar they have just typed in elsewhere. Of course he/she must also remember to invoke the Release method too, when appropriate. I suppose that he/she could alternatively use the Destroy event, saving the need to remember to invoke something special. Such a discipline is tedious though, and hardly worthy of the effort of a developer, highly skilled or otherwise.
And even the best and most disciplined developer can be interrupted inopportunely, resulting in he/she forgetting to add the appropriate code in the Release of Destroy events. Nothing will remind him/her of this except for some failure somewhere along the line!

But most developers hardly have a chance to become fully aware of the situation - it is not mentioned at all in the Help for RELEASE and it is related in all of four (4) lines in a thick guide.

The consequence of this is that a developer will only become aware of the situation after they have experienced a program malfunction as a result. Worse still, such a malfunction is most likely to occur after implementation, when the application finally encounters sustained usage with much higher transaction volumes than were ever done in testing.
Even with a malfunction experience, the vast majority of developers (98%+) will have to dig awfully carefully through a guide to catch this one. Remember, they 'know' (and see) the RELEASE command and have no reason at all to suspect it as the source of the problem(s), especially when they can display memory and confirm that the memvar is no longer there! It would take a psychic to link the failure to the RELEASE command. The less than 2% of VFP developers who use the UT (or similar FOX-related forums on-line) have a much better chance to learn the true facts.

2. For all intents and purposes, RELEASE is not performing as documented in the Help, yet it gives all outward appearances of doing so.
 Why would one search on RELEASE beyond the Help when one can confirm that the memvar which was RELEASEd is gone from the memvar pool???
 Why did the VFP Team not ensure that the Help for VFP 6 (at least, if not VFP 5 too) was updated extensively to highlight this situation when a review of VFP forums shows the resultant problem as a high-frequency plea for assistance???
 When I say RELEASE X and the Help says that RELEASE will remove the named variables and arrays from memory, then it should do precisely as I instruct it to do.

3. What induces VFP to cover-up my programming errors by providing continued access to an OBJECT which I have explicitly RELEASEd???
It is, in fact, highly unlikely that I will ever use again the OBJECT reference which is causing VFP to keep its "parent OBJECT" available in case of such a re-use. And if I should actually do so, THAT SHOULD CLEARLY BE CONSIDERED A PROGRAM LOGIC ERROR and, accordingly, VFP should raise an error. Who is doing the programming around here, anyway - me or VFP???

4. The chances of a malfunction are very high in a sustained-use, high transaction volume application where the developer, in the interest of overall efficiency, has included OBJECTs which are repetitively CreateObject / RELEASEd. Should the developer have included any reference to an OBJECT within the created object (or even outside of it, of course), then the full created OBJECT will remain in memory. Soon a malfunction in the form of degraded application performance will be reported, possibly even leading to an out-of-memory condition and a full application failure.
In fact I would wager that more than one VFP implementation has been re-written in some other language as a consequence of such a malfunction which went uncorrected and so consigned VFP to the junk-heap.

How should the behaviour of RELEASE, for OBJECTs, be revised?

A) The best revision would be as follows:
1. Any OBJECT which is the subject of a RELEASE command is to be actually cleared from memory regardless of the existence of direct references to OBJECTs belonging to it ("dangling object reference(s)")
2. The direct reference memvar(s) to OBJECTs belonging to the RELEASEd OBJECT are to remain visible within the memvar pool but are (to be internally revised if necessary) to raise an error if used for anything but a RELEASE command.
3. The Help is to be amended to fully explain this.

This will result in a program which properly executes all of the developer's instructions as he/she designed it and expected. It will also provide the necessary assistance in cases where a direct reference memvar is subsequently referenced (provided that the error message emitted is not too cryptic).

B The next-best alternative is as follows:
1. When the RELEASE command internally decides that it will not clear the OBJECT from memory because of the existence of one or more direct reference memvar(s) to an OBJECT belonging to the RELEASEd OBJECT, then it should:
 Leave the OBJECT reference intact in the memvar pool;
 Indicate, in some manner, an error (or warning) condition;
 Return an array, or fill a system memvar array, with the name(s) of the memvar(s) forcing the error condition.
2. Amend the Help to fully explain this.

This would permit the developer to quickly correct the problem without the necessity of fore-knowledge available in only four (4) lines buried in a thick book.

C The worst of the suggested alternatives is:
1. Amend the Help to fully explain, with examples and a description of consequences, the current behaviour as it relates to OBJECTs.

This will at least give anyone experiencing malfunctions a fighting chance to find the root of the problem and to fix it.



-------- END of new submission

>>>I've long wanted a STATIC variable. There are ways to simulate them, but not as nice as a true STATIC would be. I'll send forward your requests.
>>>
>>Hey Craig,
>>
>>Care to add one for me? Actually, I just put this on the UT wishlist document.
>>
>>Right now, if you have a pageframe with no tabs on the pages (Tabs set to .F.), there is apparently no way other than the property sheet to switch from page one to page two, etc. As I recall there was another way back in VFP 3.0, but that seems to have gone the way of the Dodo.
>
>Your request has been sent to the VFP development team.