>It is my understanding that the C0005 bug (problem) is probably the worst one to have. The application I created under VFP6SP5 did not have the C0005 problem, while the newly installed VFP7SP1 version does. I have two other applications that have not had this error either; VFP6SP5.
>
>My problem is, how do you trap this problem in VFP? If you can't then, this leaves VFP, the operating system, or any drivers.
>
>If we assume that the drivers are suppose to meet a specific Microsoft NT standard prior to release, then the Operating System and drivers may not be at blame. That only leaves VFP. I don't like the pointing fingers business either, but I also don't like this circle of blame.
>
>I had a Lexmark printer which would not allow printing; consistent C0005 errors. I contacted Lexmark who said "It wasn't me", of course Microsoft says if it's an NT operating system they have to be certified drivers "It wasn't me", and of course Visual FoxPro "It wasn't me". I now know that these errors are a figment of my imagination and the rebooting of my machine are just lapses in time which have been filled in with the C0005 bad experience.
>
>I am hoping that the conclusion to this will not be the fact that I and everyone else has to live with these types of errors.

Gordon,

Device Drivers that aren't written in accordance with the DDK are the problem. Harking back to the errors that were being caused by HP (and Lexmark) drivers prior to SP3 of 6.0, I listed the order of cupability. These errors were caused by a division by zero within VFP, and the driver having reset and not restored certain conditions is the FPU.

1. The driver not being written to spec.
2. VFP for not being more fault tolerant.
3. The programmer who would allow such to occur.

In this instance, I don't know what the cause of the problem is, so item 3 doesn't apply. However, 1 and 2 still do.