Hi Larry,

I did your search as outlined below.

Sure, I got 150 entries in reply. However, of the 150 69 were "PRB:", 12 of the 150 were "FIX:", 5 of 150 were "BUG:". Of the balance "HOWTO: numbered 13, "INFO:" had 11 entries, "FAQ:" had 6, and "DOCERR:" had 2. The remainder, some 30+, were informational without standard 'header'.

In addition, they were all over the map, from VFP3 to VFP7.

Finally, I reported a bug 2+ versions ago with repro code that was confirmed here as repro code. That error is nowhere to be found in this list of "problems".

So the list you refer to is less than useless - it is a time waster that offers very very minimal chance of enlightenment!

Allowing, in these sensitive times, that security bugs are a special breed worthy of clandestiny (a new word?), where is the problem with informing one's CUSTOMERS of known bugs/issues in a SHIPPED PRODUCT? As I mention often when this comes up, Fox Software regularly kept a list of known bugs available for public review and their sales continued to blossom with that list at large, so much so that MS saw fit to buy the whole shebang!

Jim

>Alan,
>Any dynamic information (and I classify BUG/PRB information as dynamic) shipped with the product would unfortunately be obsolete by the time it got to you. MS provides http://support.microsoft.com for this reason. Doing an advanced search and using PRB: "Visual FoxPro for Windows ?.0" will give you a list of all known issues (up to maximum of 150) that have cleared the review process. You can specify any additional keywords to narrow that to your particular issue.
>
>I'm not trying to make it look like there is no time spent. There is. But, IMO, it is the normal time that is spent on debugging your application. This may be a large amount of time for some and not as much for others. It may be longer because there is an actual bug in VFP. I guess I attribute that to cost of doing business. I have run into it a lot more working with Oracle than I ever did working with VFP.
>
>Personally, I think I have only run into one new bug in the production product. In VFP 6, you could not use GETOBJECT() with the Windows Management Instrumentation. I spent a longer than usual time debugging something I was working on because it wasn't working and I thought it should. I finally reported it and it did get corrected in VFP 7.
>
>What would you do if Technet (that's what support.microsoft.com is) relating to VFP were shipped with VFP? How would you use it? Would you attempt to debug your application the same way you do now? If it didn't come around, would you then search the known issues listing? How is that different than what is supplied today via the web interface?
>
>This started out as an execise in why buggy software is shipped. Buggy software is shipped for valid, IMO, reasons. It's done by every company that ships a non-trivial application to a significant (read relatively large) user base. You can't get around it. Some part of your application is not going to perform to specs for all your users. Users are dynamic. Data is dynamic. Put those two together and you get bugs eventually. If you interface with other systems, you get to buggy faster.
>
>I have shipped buggy software (I hear the gasps). Bugs have been reported/found during the testing phase of development. If they are bugs that I can reproduce in the production system, it means I didn't introduce them with this new version and most likely they won't get fixed. They have to affect a significant user base as well as affect an integral part of the system to hold up release. In case, you're wondering, some have been that significant and they were included.
>
>While I don't like to ship software with known bugs from previous versions, I have also done that. Some bugs are deemed such a low priority and it requires such a large change to what's already there, that during the evalaution process for the next release, it doesn't get selected. The one or two users that the bug affects may string me up and curse my entire family but the bug only affects them and in the grand scheme of things, satisfying 698 out of 700 users works for me.
>
>Regards.
>
>>I'm not talking about consultation. Just distribution of information. When I buy the product, what reasonable excuse is there for not giving me all the information about that product. If there are known bugs and workarounds, then that information should ship with the product. When I hit a snag, I have no idea, until I've spent time on it whether it's a bug in the product, a bug in my own code, or a by design issue that maybe I don't particularly like but will live with. If it's a bug in the software already known to the producer, then I've been forced by lack of up-front information into wasting my time.
>>
>>You make it sound like no time need be spent. Hit a snag, must be a bug, check the KB, done.
>>
>>How do you decide something is a bug without spending any time on it? And once you realize it must be a bug and check the KB, do you not feel at all that it's been time wasted?
>>
>>I still contend that shipping known bug and known workaround information with the product would reduce the amount of end user wasted time. Why should shipping the information be considered anathema to the producer?
>>
>>That is what I mean about our not being in the equation.
>>
>>

lFix = IIF(nPriority/nEstTimeToFix < 1, .F., .T.)

>>
>>so instead, how about:
>>
>>

lFix = IIF((nPriority/nEstTimeToFix) * nEstUserWasteTime < 1, .F., .T.)
>>
>>If !lFix
>>   lShipInfo = .T.
>>Endif

>>
>>Alan