Jim,

>In addition (and believe it or not) I feel that VFP itself is pretty damned good overall. Yes, I have a 3-4 item soap-box on which I like to harp (whine, bitch, push -pick it) but I believe that these are extremely important to the survival and growth of VFP. For your edification they are:

I'm with you <g>. VFP definitely is a very good product and deserves more attention. But like all languages, it has it's bugs, design errors, shortcommings, etc.

>1) First and foremost, the quality of the documentation;

Yep, very importand for newbies....

>2) Next, a desire to see a VFP-to-VFP (native and between workstations) capability for at least SQL commands and their result-sets and preferably for all VFP table-manipulating commands;

Can you explain this a bit more clear. I'm afraid I don't catch it.

>3) Continuation of improvements to the UI parts of VFP, including new/improved (UI) objects and the OOPification of MENU/REPORT-WRITER in addition to the work of positioning VFP as the premier mid-tier option for n-tier applications.

This has alway been the biggest pain in VFP. Probably due to the fact that most VFP object are not native windows controls.

>4) Revision of the RELEASE command and the Release() method as written-up and submitted.

Definitely YES..... Fix that ***** .!!

You say "The type of detailed analysis you gave on the RELEASE problems...". While I will admit to going a little more deeply than should be required (this problem has a history that needs addressing), I really wish that all except the most evident wishes (ERs) contained a thorough reasoning, requirement and benefits outline. I have to believe that such submissions would demand a more thorough consideration than a mere statement in a single sentence.

I fully agree. A wish should be fully described, and it's advantage should be noted with good reasons; Not something like: "Other Languages also have this feature so we also want this".

>By the way, do you buy the argument(s) presented for RELEASE? If so, which option would you feel is best?

I definitely want that a release method release the object under any circumstances (I still doubt for the release command). All reffering variabeles should be set to .NULL. I have no problems with a SET command that would allow the method to behave as in previous versions (E.g. SET FORCERELEASE ON|OFF).

The release command IMHO should only release the variable, not an attached object, but having the same behaviour as the Release method is not a big problem.

Walter,


Cheers