Hi Bill,

>PMFJI,

Always glad to hear another opinion< g >.
>
>But given the fact that you CAN'T programmatically be certain the printer is on BEFORE printing, the logical workaround is to provide for reprinting or undoing the transaction if you determine AFTER printing that the printer was not on, not ready, incorrect paper, etc.

Even this is next to impossible. Winspool.drv calls the particular driver for the printer. Now, as much as I've railed against HP drivers not following Windows specs, I'll use them example. I've got a 2+ year old HP Deskjet 400 at home. If my printer is turned off, the driver tells me. It also will tell me if I've got the wrong cartrdge in the printer or if the printer is out of paper. It always gives me the opportunity to correct the situation without losing what VFP has sent to the printer. In that regard (the UI), it's a well designed driver.

From my POV, this is an area which the application developer shouldn't have to worry about. You have to keep in mind that it's Windows that is in full control of the I/O, not VFP. Windows is the dog, and VFP is the tail. VFP wags when Windows tells it to, and tells it only as much as Windows "thinks" it needs to know.