>M$ KB article Q183522 says "This has been corrected in Visual Foxpro 6.0." In our experience, the statement is like the infameous helicopter joke, where the answer is totally truthful, but completely useless, since we no longer see the GPF ( 10h error ) when using third party printer drivers under Windows '95 and Windows '98 with VFP 6.0; instead, some little time after previewing / printing, the user's system hangs up, with quite a bit of flashing on the disk activitiy lamp on the computer, then finally after 10 minutes or so complete death -- all the while the computer is ignoring any user interaction on the keyboard and / or mouse. Thus, the '10h' problem no longer occurs, instead an even more dire error occurs. Hints: 1) Problem does not occur on Windows NT, 2) Problem does not occur with M$ printer drivers 3) the KB article solution about using the C _fpreset() function does not solve the problem in VFP 6.0 either

Hi Robin,

Again, the cause is the driver, not VFP. I don't think that it's realistic to expect that VFP deal with this problem, when, in fact, the fault lies with the driver. The vendor should be responsible for providing a properly designed drive. From the same MS KB Article: "The print driver is setting the numeric coprocessor so that exception handling takes place in software, not hardware. In the case of a numeric exception (division by zero, for instance), the numeric coprocessor expects the exception to be handled in software and Visual FoxPro crashes."