David,

>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.
>
As well as what you have listed (though I'm not too anxious, actually, about tutorials for beginners), the missing stuff! There is tons of it, as witnessed by KB articles in huge volumes. I'll have another submission like the one on RELEASE soon where you will se more detail.
By the way, that route doesn't always seem to work. I remember clearly a very prominent VFP GURU noting that her protestations about ISRLOCKED() going unheeded. And it remains the same to this day!


>>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?
>
I thought that it would be clear that "native" would mean within VFP command/function/object constructs.
It is too early, and really should not be my job to specify anything other than "suggestions", and then only to assist in making the wish more clear.
Hopefully there will be a more active discussion of this soon here on the UT, aimed at developing a submission for a wish.

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

Well no one really expects any wish (at least I don't) to be adopted at the next release. But the release after, or even after that. And that old saw about 'if you haven't seen it by the third release, give up because it ain't gonna happen' has been handily disproven by the recent delivery of multi-line column headers coming in VFP 7.

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

But it really isn't OUR job to worry about all of the factors to be considered in such a change. We can and should be ready to respond to questions (for clarification, say) from the VFP Team regarding a specific wish. But that's about it, as I see things.
So there wasn't enough information in my submission for you to make up your mind??? I disagree that a suggested syntax should always accompany wishes. Firstly, I wouldn't (myself) even have an additional syntax for this. If the VFP Team deemed differently, they know better than me.

>>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?
>
Frankly, who cares if it's to bellyache or for other purposes. Yes, acknowledgement of Wish items and more, like if they've been rejected, if they're in abeyance pending further consideration, if they're in analysis and review, if they're in design, etc. etc. Nothing that suggests iron-clad guarantee (they always reserve the right to change anytime, for any reason), but something that provides a "status". A 'document' regularly updated and accessible to anyone interested.
Also, more frequent updates of acknowledged bugs and of bug fix statuses, including even 'will be fixed in next maintenance release or next version release.
Mr. Gates said that MS needs to improve communications with its developers. Nothing notable has happened in the VFP area. It's time that something did.
Also, when someone in a public forum offers a "defense" for a MS practise, some way to acknowledge accuracy or state that it is wrong (not necessarily have to say the correct answer).

>>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.
>
I've answered much of this in prior statement above. I thought that I had supplied a "concise and compelling" case. I don't think suggested syntax is the way to go, and it is their job to worry about breaking existing code, not mine.

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

No thanks. They may turn you on, but definitely not me. Also, see 'improved communications' above.

You are thoroughly on board with the beta process. Some of us aren't. MS is big enough to have more than one way for users to communicate with them.

Jim N


>Regards,