>George:
>
>I too have had a problem with HP drivers (LJ4000 PCL 6). I've dl'ed the most current 1 available. I agree with your assertion that the problem is in Windows. I have 2 PrtScrn utilities. 1 written in VFP and the other written in Delphi 3.0. When I use the "correct" driver with either of these utilities, I get a garbled page. If I change drivers, the page is OK.
>
>However, If I use M$ Word, M$ Paint or WordPad, and the "correct" driver, I get a clear page. I agree that Word is a different kettle of fish, but WordPad. If Notepad is Edlin for Windows, WordPad is Edit for Windows. As I understand the method that Windows uses to print, a Windows app send the data to be printed to a printer driver. The driver handles the printing. If the driver is bad, shouldn't all apps have similar problems? The M$ products must "KNOW" how to compensate for poor driver design. It would be nice if these "KNOWN solutions" were documented.
>
>I appreciate your helpful responses and your willingness to share your hard earned knowledge. Happy Holidays!!!!!!!
>
>Regards,
Hi Mike,

Thanks for the kind words.

I can't speak to the problems you've encountered, but this one is pretty much cut and dried. The following demonstrates why Word doesn't generate the error, but VFP does. It's from the previously mentioned KB article, and shows how to replicate the problem:

= GETPRINTER()  && Select the HP6 printer.
m1 = 9 / 0 && Any division by zero will work.

The reason, of course, that this doesn't apply to Word is that you don't do calculatiions in Word.

In my mind it indicates that there are pontentially three culpable parties here.

First, of course, is the printer driver. Since this has already been discussed, I won't go any further.

Second, however, in my mind, is the programmer. I don't mean to criticize anyone here, but there are issues that should be addressed. Obviously, any formula with valid data shouldn't and won't generate such an error. For myself, if invalid data is present, my systems won't let the user generate the report until the corrections are made. Since I have a number of systems where the user is doing "heads down" entry, during the course of which data is being retrieved from other tables, daily there are a number of occurrances where the data in the other tables can't be found. When the user exits the screen, a report is generated showing what information could not be located. The user can then make the necessary entries.

When they attempt to print one of the reports, the system validates the information, and if information is still missing, again tells them where. In my mind, for me to do otherwise would be irresponsible. My systems are responsible for producing valid reports. It seems obvious that allowing an invalid operation, such as division by zero, runs contrary to that goal.

Further, I should point out, that, in most other languages, division by zero will trip the error handler. FoxPro doesn't.

Third, and finally, yes, VFP does bear some responsibility here, but not the brunt of it. However, when errors occur, I believe that the programmer should deal with the root cause (in the case the printer driver), not the manifestations of it. Fortunately, VFP in version 6.0, has addressed this issue. I find it somewhat hard to believe, that given this and the above, that I could be perceived to be some sort of apologist for MS.

Regards,