It reminds me of the complexity of printer status errors vs job status errors - which were used (as I discovered back in the 90's) because (like sockets) Windows couldn't detect network disconnect - you had to send a job to discover the error. So Windows does set and interpret PRINTER_ATTRIBUTE_WORK_OFFLINE as a proxy for PRINTER_STATUS_OFFLINE in some ways for these USB-connected printers. "See what's printing" from Devices and Printers:ĮPSON TM-T82II - Not Available - Use Printer Offline In Devices and Printers details view with status: I usually use Print Management, so you can see why didn't notice PRINTER_ATTRIBUTE_WORK_OFFLINE in my previous testing. Usbmon!DynaMonitor::PortNameNeededBySpooler+0x8fįor a completeness, here's how Windows 10 reports the status of those printers when disconnected. Setting PRINTER_ATTRIBUTE_WORK_OFFLINE is definitely internal to Windows, with a breakpoint on SPOOLSS!SetPrinterW only hit from the USB port monitor: I did some more testing too.įor a Lexmark CS725 Windows sets PRINTER_ATTRIBUTE_WORK_OFFLINE (but no printer status changes) on USB disconnect.įor the EPSON TM-T82II USB-only receipt printer that I used for testing yesterday, Windows sets PRINTER_ATTRIBUTE_WORK_OFFLINE and PRINTER_STATUS_NOT_AVAILABLE on USB disconnect. Hmm, your PRINTER_ATTRIBUTE_WORK_OFFLINE discovery is interesting. do you have any information on how PRINTER_ATTRIBUTE_WORK_OFFLINE behaves on your printers? User should fix the problem to resume." state seems proper in this case.Īs for the printer status, I'll do some more tests with other printers (TCP and USB) to verify the behaviour of Status and Attributes in PRINTER_INFO. On the other hand, printjobs sent to offline printer (status = 0) can't be printed until the connection problem is fixed, so STOPPED "Device cannot process jobs. Paused jobs are definitely not DONE but if this state is caused intentionally by some management software they don't require user intervention. Maybe the proper way to handle both cases is to mark explicitly paused jobs as PROCESSING and jobs with status 0 as STOPPED? I agree that in this case, marking jobs as STOPPED can be nearly as confusing as marking unfinished jobs as DONE. I confirm that jobs sent to offline printers have status = 0 which is interpreted by the gcp connector the same way as if they were paused here, excuse me for not being specific enough. Perhaps Stopped is a better status for paused jobs than Printed, so you can revert that part of my change if you like. TCP vs USB.)Īnyway, I can see that my change would cause incorrect behaviour in mfly's case if the driver is pausing the jobs, though normally it's only a user or admin or print management software doing that. Also, it pays to test on different types of drivers if possible. When plugged back in Offline disappeared Not Available remained until a successful print occurred. Printer status Offline and Not Available when USB unplugged. I just did a few tests now with various printers and saw something different. That'll be the driver - they can fudge the printer and job status as they like, so things are not always consistent. I think this statement above is false: "Windows marks jobs submitted to offline printers as paused". For simplicity he suggested I keep the new behaviour and remove the option. Hence my desire to avoid it with that change.Ī previous version of my pull request ( #215) included an option to enable/disable this behaviour, and in there you can see Jacob and I discussing it. Stopped ("Was in progress, but stopped due to error or user intervention") sounds like an error and doesn't really describe the state of our jobs - which have successfully made it out of GCP. Upon arrival (while spooling) jobs are paused for processing (accounting etc) before being released either automatically or at a later time by the user. I'm interfacing the GCP connector to our print management solution.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |