>Hi, George (hope the holiday went well)

Yes, it did, thank you. And I hope your's was the same.

>>Always glad to hear another opinion< g >.
>Well, I don't know how useful it is, but I will soldier on < bg >

Ah, c'mon. Hearing another opinion is always useful, IMO.

>>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.
>
>My only point was that at sometime during or after the transaction, it becomes evident that the print failed (it may only be when the user goes to get the receipt, and sees that it is not there) at which point the application should provide the user with a way to undo/redo easily.

Understood, but doing this from within VFP is, well, not practical. In thinking about this problem, I thought that the API function GetLastError() might help, but then again, it needs to be called immediately after the error occurred. There's a very high degree of probability that this is a dead end too.

Further complicating this is simply that many printers have their own memory and report their own errors. Even Windows doesn't know when that happens.

>My wife works in retail, and I have seen how their POS "handles" this problem. Customers don't like it when you have to void an entire card transaction by doing a return because "the dumb computer" messed up, the printer jammed, etc.

Oh yes! Perhaps easiest is a re-print option, wherein the last < pick a number > receipts could be printed.

>If its not possible to wag the dog here, then if possible we as defensive programmers should provide a solution when the dog fails to live up to its responsibility. If the job spools, it should be there when we correct the printer problem and so we should allow for a reprint, if it doesn't (or its gone, or its not reliable that this will be the case) we should provide a mechanism to easily and quickly procure the desired result.

See above.:-)

>At least I am assuming quickly is a requirement, I haven't seen too many checkout queues where people liked waiting. :)

Especially at Christmas time (and shortly thereafter)< g >.

>I guess what I am getting at is that a restatement of the problem might be more fruitful in a situation like Andrus is facing --Maybe the problem isn't so much finding out what the printer did as much as it is making sure the transaction completes correctly. If the printer can't tell us, we need to make other arrangements.

My thoughts exactly.