Bill,

I can see why you work for a logistics company. *g*

You're absolutely correct. Exception programming is the answer IMO here.

Good call.

Best,

DD

>Andrus, George, et al,
>PMFJI,
>
>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.
>
>Andrus, if you have any control at all over the design of the card transaction routine, this would probably be a better avenue to take--to allow for the fact that mistakes occur and sometimes things need to be redone/undone. Decoupling the transaction from the printing would be one way, rolling back the transaction if the printing fails is another. A third idea might be to print something to the printer before committing the transaction to the card authentication agent (maybe the header of the receipt). If this initial printing fails, then you can rollback the transaction before it gets sent.
>
>I understand that sometimes its unavoidable, or more difficult, or less secure, but if at all possible providing for a reprint, and/or an undo of the print would be more robust than digging around in Window's guts, and still not being sure.
>
>If its not possible to change the transaction, then I guess you have to rely on the user ensuring that the printer is ready, so lots of warning, and reminder messages become the only remaining safeguard, and since you are looking for a way to ensure its on, you know this is less than optimal. :)
>
>Just my .02, but sometimes refactoring is better than finding a technological solution.
>
>Best,
>Bill