I stumbled across this problem. In my use case, I had a script that iterated over all files in a directory and invoked the "Print" verb on them using ShellExecute. (So simulating the user going through each one, right clicking, and then choosing "print.")
The results are fine when you're only working with small numbers of documents, but with 10's or 100's there are always a few that are out of order.
It's hard to tell if the problem is with the program that's handling the "print" verb, or with the queue itself. (In my case, each time I'm invoking print I'm probably invoking a new instance of the program used for printing. This means that vagaries of execution time/scheduling could mean that the "print" program for document #2 actually submits job to the queue before document #1.)
It seems like there might be something going on with the queue too though.
I created a program that prints documents while watching the queue. The first version worked in the following way:
ShellExecuteEx to print document
Wait for document to show up in printqueue
Print next document
In this version, a few documents would still print out of order. Second version was the one that worked:
ShellExecuteEx to print document
Wait for document to show up in printqueue
Wait for spooling to complete (PrintSystemJobInfo.IsSpooling == false status in .NET)
Print next document
This second version prints the documents in order every time. This leads me to believe that when you're submitting a bunch of documents, there's a weird period where it's a race to see which one get's spooled first.
I'm not familiar with the ins and outs of the Windows print system though. It could be that a job shows up before the program that generates it is done sending all data. This would mean variable execution time of the program behind the "print" verb could be causing the issue.
I stumbled across this problem. In my use case, I had a script that iterated over all files in a directory and invoked the "Print" verb on them using ShellExecute. (So simulating the user going through each one, right clicking, and then choosing "print.")
The results are fine when you're only working with small numbers of documents, but with 10's or 100's there are always a few that are out of order.
It's hard to tell if the problem is with the program that's handling the "print" verb, or with the queue itself. (In my case, each time I'm invoking print I'm probably invoking a new instance of the program used for printing. This means that vagaries of execution time/scheduling could mean that the "print" program for document #2 actually submits job to the queue before document #1.)
It seems like there might be something going on with the queue too though.
I created a program that prints documents while watching the queue. The first version worked in the following way:
In this version, a few documents would still print out of order. Second version was the one that worked:
This second version prints the documents in order every time. This leads me to believe that when you're submitting a bunch of documents, there's a weird period where it's a race to see which one get's spooled first.
I'm not familiar with the ins and outs of the Windows print system though. It could be that a job shows up before the program that generates it is done sending all data. This would mean variable execution time of the program behind the "print" verb could be causing the issue.