Tom,

I couldn't agree with you more!!

Think about it a little. Who are the real knuckleheads who know the day-to-day scoop regarding VFP? We are! <g>

I'd really like to encourage Jim to start with his list and I'd think that the fox.wikis would be the ideal place for this type of endeavor.

Jim??


>Jim;
>
>Disclaimer: This is not directed at you but since you are “such a nice guy” I decided to address this message to you. Am I a nice guy or what? Do not answer that! :)
>
>
>One thing we shared from the dBaseII days through to about FP 2.6 was information about incompatibilities. Yes we share some information today but there is now much more hardware/software then before. Sometimes you hear, “Do not use HP Drivers”. Other times you hear, “Do not use Windows drivers”! All this for HP printer problems! Both approaches have validity. When we wrote our own drivers we knew whom to go to solve problems. I am not advocating we create our own drivers by the way!
>
>Problems related to specific video chips/cards, mother boards and BIOS were exchanged between developers on Compuserve, etc. along with specific drivers which gave problems. Geroge Goley made a statement which is burned into my mind, “One computer in 500 will not work with FoxPro”! That was almost 10 years ago and now things are certainly more complex. Add changes to operating systems (actual improvements for the most part but not always), interaction of software and networks add to the list of probable causes of VFP crashing.
>
>I still think we should use the Wiki and UT to publish a list of problems found while using VFP or earlier versions of FoxPro. This should include structured information – O/S, mother board, chip set, BIOS, network and versions of everything used. It is not enough to say NT 4.0 – you have to know the service pack number also. It is a real pain when one computer or client has a problem and the problem cannot be duplicated elsewhere.
>
>How many of you have had a happy client who decided to upgrade hardware and/or operating systems or networks? Anyone not have a problem when such an event occurred? This reminds me of my fathers television repair business. An actual call from a client whose television was repaired in 1948, was received in 1958 and the client called to inform us that her television did not work. Since my father was the last person to work on it he was responsible!
>
>I have been conditioned by this event and am not surprised when a client calls who just upgraded to the latest greatest computer goodies and still wants to use a FoxBase application created in the late 1980’s.
>
>It is not practical for any software vendor to publish a bug list for the public. We are members of the public and not a special segment of society because we use Microsoft tools and call ourselves developers or what ever title you prefer.
>
>Does anyone out there remember something I state very often about testing an application before delivering it? My clients each have a hard disk assigned to them, which is in my library. I duplicate as much of their system as I can including the network used when possible. Testing is a serious business with me. I have clauses in my contracts that are hardware/software specific. Any changes made to the original configuration without notification and approval by me releases me from any responsibility.
>
>I try to protect my client and myself. Educating your client is your responsibility and if you are not doing it you are remiss in your business practices. Too many developers know how to write code but may do not know how to develop systems and business relations.
>
>After receiving a few “flavorful” e-mails from some UT members I expressed myself yesterday and can take it or leave it. I do not have all the answers but would like to see us get together and help each other rather than take exception to one word or statement. If you do not think there are any problems with Visual FoxPro then that is fine. Consider yourself lucky. If you have had problems then what we need is a rational approach that will assist others as well as yourself.
>
>There are people on this forum that are walking encyclopedias and know specific hardware/software combinations that are known to have problems with VFP and other applications. They are a great source of information. Now does anyone have a suggestion about how to put or energies together and create something useful to help publish bug information? We can let Microsoft know how we feel but I think we can do more on our own to solve many of the problems we find.
>
>I have worked with electronics since I was a kid – long before many of you were born. As an engineer I was constantly fighting hardware and software problems. One type of problem I hate is the situation where more than one vendor is involved. A problem is discovered and you attempt to determine its source. You call a vendor and they point the finger at another vendor because more than one party was involved. This is a difficult situation.
>
>Our field of endeavor is complex as you have many types of hardware and software interacting together. It is amazing things work as well as they do. Or do they? Perhaps you should stay awake at night and worry if all the electrons and binary bits act as they should – at least in your mind. You see folks those little electrons are the entire problem. We just have to learn how to direct them as is required.
>
>Tom