0

I have seen this question which was closed as a duplicate to this question. Unless I am misunderstanding the answers neither question has a valid solution for me.

I am trying to create POS style printing. My requirements seem simple.

  1. Send to thermal printer (RawPrinterHelper)
  2. Validate print job success (?)
  3. Send to backup printer if failed or in que too long. (RawPrinterHelper)

For the first and third points I have resorted to the RawPrinterHelper. It works great but SendStringToPrinter will always return true as long as the printer is installed. Even if the printer is not setup correctly and can never finish the print job. I don't think I can used the RawPrinterHelper for validation.

The questions linked above use the ManagementObjectSearcher on the Win32_PrintJob to poll for information about the print jobs. I have also used the ManagementEventWatcher on the Win32_PrintJob to poll for new and deleted print job events. These solutions work for validating print jobs in most scenarios, but rarely thermal printers (total pages can't be relied on). Polling for information to validate printjobs doesn't seem like the best option. I was easily able to miss the information printing test pages.

For these reasons, the ManagementObjectSearcher and ManagementEventWatcher won't do the trick for me either.

The only solid solution I can seem to find is by Duncan Edwards Jones here. Thanks by the way if you come across this I've learned a lot from you. Duncan shows how to use the FindFirstPrinterChangeNotification to get events about the job status. I have tested this and I can say it works nicely for validating if a print job was successfully printed when it was removed from the print que.

Although Duncans solution is great I would need to go through it and make it x64 compatible with my project and probably do quite a bit more learning and understanding to get it into c#.

Is Duncans method of using FindFirstPrinterChangeNotification still the appropriate way to determine if a print job left the que successfully?

Part of me feels like I'm working too far back in time and .NET must have a solution for this problem now.

Update: It will be a requirement for the end user to have the printer installed and test page functioning from within windows. I won't support anything windows doesn't recognize.

clamchoda
  • 4,411
  • 2
  • 36
  • 74
  • 1
    Yeah you are after a fairly specific thing here, and thermal printers are notorious for being well thermal printers. Its up to language and firmware and how you have programmed it to take care of it self, sometimes the windows drivers have no idea about them. However the good thing is you found something that works, at least this is a glimmer of hope. however i can see this question needing a bounty – TheGeneral Nov 03 '18 at 06:53
  • @TheGeneral Sounds like this is going to be fun. I am eligible tomorrow for bounty I will offer one. Thank you – clamchoda Nov 03 '18 at 20:05

1 Answers1

0

The PrintQueueWatch library has been made x64 safe and is up on GitHub at:

https://github.com/MerrionComputing/PrintQueueWatch

However - as Michael Randall notes - thermal printers don't always use the Microsoft Printer Driver subsystem or APIs so it may not work for that case.

Merrion
  • 558
  • 4
  • 8
  • I did some extensive testing and the monitor is not quite perfect. Sometimes it reports incorrect print job names as "Low level document" – clamchoda Feb 15 '19 at 05:05
  • Yeah - the monitor reports the information that the print spooler has- which is the information given to it by the application(s) doing the printing. – Merrion Feb 18 '19 at 10:29
  • I write an empty application to load up 1000 print jobs named Job1, Job2, Job3, Job4, ect. every so often on the job deleted event it tells me the print job deleted was named "Low Level document" instead of the corresponding name given to it by the application. The PrintQueueWatch is so awesome it would save me a lot of headache but I couldn't seem to solve this issue. I only ever saw it happen on Windows 7 Professional 64bit. – clamchoda Feb 19 '19 at 16:26
  • Sorry for the confusion. I believe it was being reported incorrectly as "local downlevel document" not "low level document" as I specified in my earlier post. – clamchoda Feb 19 '19 at 16:38
  • Hi - is the printer you are printing on attached to the local machine? It seems to me like an asynchronous communication thing - i.e. when the spool monitor tries to get the name of the document it has already been deleted or marked for deleting in some way? You could get the name for each JOB_ID into a concurrent dictionary in the JOB_ADDED and/or JOB_WRITTEN events..but it feels a bit hacky. There is some extra infor from PaperCut here: https://www.papercut.com/kb/Main/RemoteDownlevelDocument/ that may help? – Merrion Feb 20 '19 at 19:13
  • Yes the printer was attached to local machine. I was doing some testing by spooling up 1000 print jobs into the queue while the printer was off or in error state to make sure they stayed in the queue. Then I would manually highlight all printjobs in the windows printer queue and delete them all at the same time. This is when I noticed the deleted event missing printjobs with the "local downlevel document" issue. Thank you for guiding me towards a fix I will take a look – clamchoda Feb 21 '19 at 18:36