Rick,

I didn't think you were affiliated with MS... Just that you probably know some of the more powerful VFP poeple there. A "direct line" so to speak.

Perhaps I am expecting a bit much, but there *needs* to be more in the basic VFP books (Help especially).
Some simpler examples which easily pop to mind:
1) How do Timers really work in a mutli-tasking environment?
- Do the pop at expiration regardless of who is in control, or do they only pop once the VFP issuing prog has resumed control?
- Do they count only the time spent *in* the VFP program or is real elapsed time counted?
2) How do buffers work in a networked environment?
- Will I only see committed changes from other stations (and when) or will I see them as they build but before they TABLEUPDATE?
- What about my buffers vis-a-vis other stations?
3) How does locking work with
- multi-sessions on one PC?
- In a network where some apps use table buffering, some use row buffering and some use none?
- Do the "old" commands like UNLOCK, FLUSH, etc operate the same on buffered tables?
- Does SET REFRESH work for more than BROWSE?
4) What is the precise "default" behaviour for each event of each control?
- Which of them *can* be suppressed by NODEFAULT* and which of them happen regardless?
5) If a ComboBox dropdown always has exactly 7 lines only, why not say so?

Given the time I can list much more.

Now I would like to know how third-party books can address these issues ACCURATELY? From what I have seen, the vast majority (all that I have read) are based on observation of usage, no doubt with intimate knowledge of the doc and the knowledgebase.
But most of these issues are not the sort which can be answered strictly by observation - the perception will be accurate for a specific set of conditions but likely not for some other set. As I like to repeat... using observation alone I can "prove" that the sun revolves around the earth.

Just look at the KnowledgeBase and count up how many times the response is "working as designed". WHY do we only learn of the design objective in such articles? - isn't the docs the place for such information? Wouldn't putting it in the doc save lots of people lots of (needless) trouble?
Also, look at how many times the same question pops up in forums like this. COuld MS have done a better job of explaining the READ EVENTS or the fact that deleted records still matter for Primary/Candidate keys? Or any of the hundreds of other "repeat" questions which appear less frequently thatn the two mentioned?

Finally, there is growing talk about how VFP seems "stagnant" in its attraction of new programmers. It has always been my perception that FP and VFP always had too many people who "tried it" and gave up on the basis that it was too complicated.
Well, more complete and clearer documentation would do much to address those issues.

Most importantly, addressing people like yourself - HOW CAN BETTER DOCUMENTATION POSSIBLY HURT THE PRODUCT????
To my knowledge, good documentation never stood in anyone's way.

And my comments are limited to VFP. I have no knowledge of the quality/conetnt of VB or other documentation. Long ago I did dabble with C (from MS) and found its documentation voluminous but "chopped-up" and I early decided (not because of the docs) that I simply did not like C as a language.

Cheers,
Jim N

>>The VFP docs have considerable volume, but they still lack *MUCH* information.
>>And the KnowledgeBase is a poor substitute.
>
>I don't agree. The documentation for the various developer products
>are what I would consider adequate. The VFP docs do provide a lot of
>useful info. Same goes for VB. It's there it's just not necessarily
>easy to find - online books and searching can remedy that problem.
>
>I think you're expecting too much from documentation. For a product
>as complex as VFP you cannot expect to print a manual that covers
>every little nook and cranny of a product. That's what specialized
>3rd party books and magazines are for.
>
>VFP is no different than any other tools from MS or otherwise. Just
>take a look at the Delphi docs for an example. There's tons there
>but you also will not find the down to the wire information that
>you only gain by experience and participating in online forums.
>
>SourceSafe however is on a whole other level than this . The online
>docs that come with it require its own dictionary to decipher the
>terminology that is used to describe what should be a simple process.
>
>And FWIW, I'm not affiliated with MS...
>
>+++ Rick ---