Knowlege Base Article Q183522 says the problem is fixed in VFP 6. My point is that the problem has gotten worse. The same article lists 3 solutions, and the first is to use Microsoft's own drivers for the offending printers. The third solution involves coding a call to the Visual C run time library ( msvcrt20.dll to access the _fpreset() function. Yes, resetting the floating point processor is the coding fix.

I have also heard rumor from some of our customers that SBT Accounting has a fix for their own coding. Are there any SBT developers out there listening? A coded fix would be a nice contribution to the Visual Thread, without jeopordizing accounting systems market share, don't you think?