Jim,

>OK George, I'll keep things rolling (as best I can). . .
>
>>>We simply do not communicate very well together, George, so I'll leave things where they are. Suffice to say that the KB article is actually next to useless and doesn't state that it is still a problem in VFP7.
>>>I still cannot 'get' the idea that the VFP Team doesn't know what fixes they've implemented **before** the public actually obtains the final product!
>>
>>I think that we don't communicate very either, Jim. However, I think that from your statements, you really don't understand what's going on here. You keep referring to the "VFP Team" which, if I understand correctly, you think is also responsible for updating the KB. Now if I'm wrong here, I apologize, and you can disregard the rest of this message. If I'm correct, however, here's the scoop.
>>
>>The "VFP Team" is most certainly not responsible for updating the KB. As I understand it, that's the job of Product Support, which, BTW, covers all products. Now if I'm incorrect in this, I'll trust Garrett Fitzgerald, who works for Product Support, to step in and correct this and what follows.
>>
>>Product Support is responsible for writing, editing, reviewing and updating the KB articles. The articles are reviewed periodically, and given that there are literally thousands of articles to review, it's not terribly surprising that those covering VFP haven't as yet been updated. As a point of fact, it sometimes takes weeks, if not months, just to get a new KB article in there.
>
>Your perception is absolutely correct. If what you describe is even only close to what the procedure actually is then I am waaayyyyy out to lunch!
>
>But I've gotta say - you guessed it - that's MOST UNhelpful to the VFP community! In fact I see it as downright obstructive.

I won't debate the point except to say that this isn't just limited to VFP. This applies to all MS Products.

>Let me take a simple issue first: KB article "thrusts" NEVER result in improvements to the VFP product documentation. This is a perfectly logical extension of the process that you describe and it is borne out by years of observation.

The VFP or Fox team is certainly aware of the existence of the KB articles. However, and I'm guessing here that you're under the impression that the VFP is directly responsible for the documentation. I don't believe that's the case either. Sometime back, I pointed out some errata in the docs to the team. The response I got was that my communication was being forwarded to the "documentation team".

>For instance, let's say that Product Support gets an overload of calls over a period about "problems" with VFP's ComboBox. They smartly decide that some "How To" articles would be the antidote so they write, edit, review and publish them. They've done their job, but the VFP Team is none the wiser that, most probably, the content of their documentation is the cause of most of those calls in the first place! Nobody, most especially not the novice, is helped by this procedure.

How many times has a member of the VFP Team (particularly Mike Stewart) pointed to a KB article? Quite a few. My impression is that they are accutely aware of the existence of the KB articles.

>Now let me discuss the 'fix list for VFP 7". From your description it is up to Product Support to gather all of the prior BUG articles for VFP 6, 5 and 3 and ferret out those that do not have a 'fixed' indication attached.
>Then they have to try each one out to learn if it is fixed or not. Those that are 'fixed' get added to the list of fixes. When they have been through the whole list then they can write, edit, review and publish the "List of Fixes in VFP 7.0" article. With any luck at all we just may get it as VFP 8 is released! Those that remain as bugs in the current product require each of their articles to be updated to now include VFP 7.0 in the 'applicable to' line.

The other side is that the KB cannot be updated piecmeal without giving the impression that an issue wasn't addressed when it may very well have been address. Further, they can't even start working on what's been fixed or not until the software goes "gold". IOW, is RTMed.

>I'll end by discussing the BUG Reporting facility with the (new found) knowledge that these go directly to Product Support and not to the VFP Team.
>A submitted bug must be reproducible to be able to be squashed, and we all understand that. But VFP has sooo many different mechanisms/SETs that can influence processing and Windows has even more (not to mention different versions at varying fix levels). There is a very high probability that an abunbance of the submissions prove to be not reproducible in one (or even two or three) trials. We have witnessed that here more often than not in the 50+ VFP7 bugs reported on UT! The Product Support group can legitimately dismiss the report as not reproducible! They cannot contact the submitter (at least the 'regular' submitters) to learn more factors that might be implicated because submitters mandatorily are anonymous!
>I contend that the VFP Team has more in-depth knowledge of the product that would (often) let them deduce mitigating factors to assist in reproduction of the problem submitted. I contend that the VFP Team has a vested interest insolving problems rather than just handling them.There is a HUGE difference!
>There must also be a "political" problem with the current practise. After all, if I was the Manager of the VFP Development Team I wouldn't take kindly at all for some outside group to be declaring bugs in *MY* application. I've gotta believe that there is an additional layer of "review" imposed in the system just because of this.
>
>The procedure explains WHY 99%+ of the bugs reported here (UT) for VFP7 remain unacknowledged in the KB. I say that means that a change is needed, not that the current practise is in any way acceptable or sensible!
>
>I never would have guessed that things worked the way they do and I doubt that many regular VFP users did either.

If people report bugs and fail to provide a detailed description and code sample to reproduce the bug, IMV it's as good as not reporting the bug at all. I recall one post here (I can't recall who made it, unfortunately) where the poster stated that he wouldn't give further information beyond what he had already posted because it wasn't his job and he didn't feel that he should help MS make money.

That's a pretty narrow view of things in my opinion. The saying back in the 1960's was, "You're either part of the solution, or part of the problem." In this case, the poster is part of the problem. He does nothing to help the VFP Community except gripe. Another saying (biblical) is, "It's better to light a candle than to curse the darkness." I like to light candles.

As far as the quality (in general) of the VFP (and other Microsoft) documentation, I've had the experience working with products from other vendors and their documentation. Certainly, the stuff from MS isn't perfect, but it is consistently the best, most accurate, and most informative. Would I like it to be better? Sure, but given what I've just said, what's out there is great by comparison.