Jim,

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

Do you mean the style of documentation (need more tutorials for beginners, etc) or errors in the documentation? I've seen MANY doc errors reported and corrected during my VFP beta experience, expecially in the early stages.

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

Interesting concept. I understand "between workstations", but what do you mean by "native"?

What are your suggested additional parameters or command options (suggested syntax) for this capability?

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

Submitting enhancement requests during the design phase, as you have done through Craig, is the best way to get major changes considered. During the beta, the feature set is pretty well fixed, although a few ER's during beta have been included in the final product or in a service pack.

I'm guessing that the design phase and alpha testing is probably well under way by now, although I have no specific knowledge of that.

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

I haven't wrestled those out as thoroughly as you have, and I'm sure that there are many factors to be considered in such a change. Walter's idea (or was it yours) of a SET FORCERELEASE ON|OFF is an example of suggested syntax, that should always accompany enhancement requests, if possible.

>A near wish is to see improved communication between the VFP Development Team and us VFP developers. But since this isn't directly related to the product, I harp on that separately.

By improved communication, do you mean perhaps "more direct communication" or "more opportunity to bellyache" :), an acknowledgement of wishlist submissions, or what? What would "improved communication between the VFP Development team and us VFP developers" look like to you?

>That's them for me, and in due course I will submit similar to what I just did for each of these.

As noted above, the design phase is the best time for that.

>I should note too that I have been trying to get improved documentation (especially Help) for years now, trying every means available to send the message. Frankly I have seen (what amounts to) zero improovement despite all of my attempts.

A detailed list of specific suggested improvements, with thoughtful justification and benefits analysis of each, would be the best approach. Maybe you've already done that. In your message, however, you said "improved documentation" -- I don't have any idea what you mean by 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.

Bingo. The designers and development managers have to deal with enhancement requests from within and without, long lists of confirmed bugs, overall Visual Tools strategies (such as HTML Help, COM/DCOM/MTS, and now COM+), internal political issues, backwards compatibility issues, and a very loyal, stubborn, and creative user base. Every decision of what features to add and what bugs to fix must be somehow weighted by a cost/benefits/schedule/staffing analysis.

A concise and compelling case, backed by benefits analysis and suggested syntax (especially giving consideration to not breaking old code), is much better than a general "make this better" kind of request. Still, the decision will probably come down to some kind of cost/benefits analysis by MS.

So... I again suggest that you consider applying for the beta (email to betareq@microsoft.com with "Visual Foxpro" in the subject line, and your contact data in the body). You also should include a description of your computer(s) and specifics of what type of testing you would be doing. You'll then probably get an automatic email response telling you everything I just told you.

Regards,