Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 782
  • Last Modified:

Job "sent to printer" but still remains in queue

I've written my own unidirectional port monitor for both win9x- and NT-based platforms. It works perfectly on win98, but I have an idiot problem with the NT version.
The port works well, does perfectly what it has to do, but after enddocport function call (i.e. after finishing the printing) the jobs still remain in the printer queue having "sent to printer" status on XP or "printed" status on NT4SP6. (all pages are printed and all bytes are sent).
The job normally has to disappear from printer queue unless "keep printed documents" is checked, hasn't it?!.
More, on system restart, all jobs remained in queued are sent to printer (i.e. print monitor) again! More more, even I delete all of these jobs from queue, they still reappear and are sent to printer again at the next system restart. Has anybody a logical explanation and/or a workaround for this?

0
zoltan082098
Asked:
zoltan082098
  • 3
  • 2
1 Solution
 
DanRollinsCommented:
I don't know what criteria the spooler uses to decide when it can put the boot to a finished job.

BUT... If this behavior only result when your monitoring software is in place, you would have to look very carefully at your own code.  Perhaps there is some handle that you are indavertently leaving open.

So first thing to do is verify if the problem goes away when your software is not in place.  If that is the case, then I'd open the Task manager and watch the number of handles and User object and GDI objects as your monitor processes a job.  There should be as many when  a job is finished as there were when started.

-- Dan
0
 
zoltan082098Author Commented:
No, unfortunately it may be a wrong direction. That is, usually I'm not constrained to clear everything after the current job, because all of the consecutive jobs may share the same database (handles, user objects, etc, of course I don't mean the effectively sent data). This database is created by OpenPort, freed by ClosePort; on the other hand jobs are bracketed by Startdocport and EndDocPort.
0
 
zoltan082098Author Commented:
No, unfortunately it may be a wrong direction. That is, usually I'm not constrained to clear everything after the current job, because all of the consecutive jobs may share the same database (handles, user objects, etc, of course I don't mean the effectively sent data). This database is created by OpenPort, freed by ClosePort; on the other hand jobs are bracketed by Startdocport and EndDocPort.
0
 
DanRollinsCommented:
I know very little about your project or how well you are implementing the port monitor.  So forgive me if this is a stupid question:

The documentation for EndDocPort says:
>> Monitors should call the Win32 SetJob function to inform the spooler that a
>> print job is completed. A port monitor’s EndDocPort routine should call SetJob with
>> the dwCommand parameter set to JOB_CONTROL_SENT_TO_PRINTER.

Are you doing that?

-- Dan
0
 
zoltan082098Author Commented:
Bingo!
The most stupid thing is that even in win98's DDK says the same...
0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now