Rick,

I agree with most of what you say.

But I do not think it is up to "us" to accept less than spectacular documentation from any vendor. To do so is to perpetually let those vendors off the hook.

My simple questions, and dozens more like them, cannot possibly be answered by careful practise and observation alone. What is required is AT LEAST the "base" design objective. This would include presentation and behaviour under those circumstances where thing would differ from the "normal" (and, of course, we also need the "normal").

Suppose the cost went up by 5% or 10% or even 15% to DOCUMENT VFP "PROPERLY". They just might re-coup that "cost" in "support" (KnowledgeBase, VFP forums, Help line etc), increased sales (much wider user base) etc. They might not even get too many gripes passing on some of those additional costs to the buyers (us!).

Really, as it stands now, the majority of us are truly "flying by the seat of our pants" when it comes to getting anywhere near "fancy" in VFP - we are relying *not* on what is DOCUMENTED, but what we have OBSERVED and put hope against hope that it "will stay that way". This is not really a safe way to deliver a "production"-class application.

Well, I've beat this one to death. In closing I repeat: Better documentation for VFP cannot hurt the product.

Cheers,
Jim N

>>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?
>
>Those are valid questions, but honestly, those kinds of questions are answered
>best by experience. Can you point to any full scale development product that
>provides docs like that???
>
>I know I try to document every idea or question that is raised with Web Connection
>but even so there are a lot of things that you simply have to figure out on your
>own. There are too many paths to solutions that make it impossible to find
>into a book or manual (let alone trying to get some work developing done).
>
>I think VFP fares much better in that respect than most others because tuning
>is a lot easier than most other tools. Try digging into DAO and tuning the
>engine for optimum performance. There's a lot more to it than optimizing
>an index!
>
>
>>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.
>
>Uh, that's what 'experts' are for. But I have to be honest - there are more
>worthless books out there than good ones and sadly the people who need to
>buy a book are unlikely to be able to tell the difference between a good
>book and bad one.
>
>I think the problem you're faced with is due to the fact that the dev
>products are changing so drastically and so quickly that it's hard to
>become an expert anymore. Used to be if you knew FoxPro in DOS the transition
>to Windows took some getting used to but you could transfer most of that
>knowledge. That cycle was something like 6 years long. Now, we're not just
>looking at a product but development platforms, networks, the Internet...
>
>No magic answer, but look at what you can do today compared to back then
>and with a lot less effort including not having to know all the tweaks.
>Optimum applications always require tweaking, but it's also not required
>for every application.
>
>
>+++ Rick ---