>>>>Hi, Fred...
>>>>
>>>>When I first read your message, I wondered what was in those doughnuts you've been eating <g>, but figured I'd give it a shot. (I've wondered about video drivers, but never suspected a printer driver.)
>>>>
>>>>And you were right!
>>>>
>>>>I don't have an HP driver, but I do have a driver for a color laser printer called Tectronix (or something like that). The driver is from the manufacturer. When I remove the driver, everything works OK.
>>>>
>>>>Now the hard part....explaining it!
>>>>
>>>>Thanks for the info!
>>>>
>>>Hi Kevin,
>>>
>>>PMFJI, but what's happening is that the printer driver is setting the math co-processor to a state where the calling application (in this case VFP) is expected to handle division by zero. VFP expects the co-processor to take care of it. See Q183522 in the MS Knowledge base for further details.
>>>
>>
>>Hi again George < g >
>>
>>Is there any downside to the FPSET() solution in the article you mention? Can fooling with the co-processor that way cause problems??
>
>Not that I'm aware of, Rick. I should add, however, that I'm not very familiar with this function. While my applications' reports are printed almost exclusively on a variety of HP printers, I've never had this happen to me. The reason is that all summary reports (and I deal with quite a few), are generated via query, with 90% of the math work being done in the SQL statement. What remains, has checks for division by zero, so...
>
>Perhaps someone who has actually had some experience with it might be of more help. I'll try to remember on Monday to check my MSDN library at the office for more information on the function. If I find anything, I'll re-post.

Thanks, George