Print jobs don't queue, pulled straight into printer memory - no way to see real status

1
votes

I have been asked to develop a print monitoring utility which will receive a print job from a customer system, route it to a printer and then trigger an update in the host system with success status whenever the printer completes the job.

I found at least two ways to get print job status from a printer queue - use WMI to query Win32_PrintJob or use API to winspool. Both methods worked just fine when I tried to print to a printer that was disconnected - I was able to get a list of jobs with statuses waiting for the printer to become available.

Now I am trying to test a scenario when the printer is out of paper or jammed. Unfortunately, in this case the print jobs are removed from the print spooler queue and pulled to printer memory, waiting for the user to put more paper or resolve a paper jam. The print job is no longer in the queue but it hasn't been printed, so I can really update the host system with success status. I found a few articles talking about using PJL or printer specific APIs to get that information from the printer itself but I haven't succeeded with those. Is there any way to configure Windows spooler queue to retain in the queue until it has actually been processed by the printer?

Thank you!

1
windowswinapiprintingwmispool
I don't understand what you mean when you say the print jobs are no longer in the spooler's queue. They most certainly are. The Win32 functions EnumJobs and GetJob will return info on them. What API are you using? – Carey Gregory
From MSDN: "Port monitors that do not support TrueEndOfJob will set the job as JOB_STATUS_PRINTED immediately after the job is submitted to the printer." If the printer vendor thought it was too much trouble to report the true status (even assuming the printer supports it) I imagine that writing your own code to do it would be an extreme PITA. Before doing anything else I'd ask the vendor if they have an updated driver supporting this. – arx

1 Answers

0
votes

Thank you, arx for posting that MSDN link, that's exactly what I was suspecting. I guess that particular driver I was testing with didn't support that true status.