PDA

View Full Version : Timing a print from click to clunk



sponge
08-18-2005, 11:33 AM
Hi,

Is it possible to write vba code to time a print from clicking on OK to when the last print comes out for the document in Word?

I'm trying to run some tests on PCL vs. PS

Any help would be much appreciated...

Thanks!

fumei
08-18-2005, 01:58 PM
Hmmmmmmm.

sponge
08-18-2005, 02:10 PM
Uh oh.

Am I heading into uncharted waters?

Ken Puls
08-18-2005, 02:39 PM
I'm an Excel guy, not Word as is Gerry, but I can't even fathom how you'd do this, unless you had the expertise to program something that could talk to your printer. I could easily be corrected here, but this is my understanding of what happens in most enivornments...

You click print
Your software "spools" the job into the printer's RAM
Your computer essentially washes it's hands of the print job at that point.
It prints (from the printer's RAM, NOT your PC's RAM)

Depending on the amount of RAM in the printer and the size of the job, the time between the print job finishing on your PC and finishing on the printer could be very different.

Personally, if it was that important to me... I'd use a stopwatch. :)

sponge
08-18-2005, 03:06 PM
Yeah.. I was using a stopwatch earlier.. but I found that there was much room for error with it.. :(

Ken Puls
08-18-2005, 03:32 PM
LOL!

I thought I was being a smarta$$! How much to you do this? And why, if you don't mind my asking?

Jacob Hilderbrand
08-18-2005, 04:07 PM
I wonder if we can check for changes in spoolsv.exe. Unfortunately the process is always running so no help there...

Ken Puls
08-18-2005, 04:11 PM
Even so, Jake, if the printer has, say 64MB of Ram, you could end up with a cleared print spooler long before the job is done.

Killian
08-19-2005, 02:29 AM
I think the short answer is No.
The issue here is that at application level, once you've sent a job to print, that's it. Word doesn't know or care whether it prints or not - that's the printers business.
So this information can only come from two sources:
1) The printer driver. I'm not certain how print drivers work at this level - if the OS checks the print queue preiodically when it's active (which I suspect is the case) then you could concievably simulate this by setting up some API functions to emumerate the number of print jobs (every 100ms or something). This sounds overly complex, but not compared with trying to intercept a low level windows message - which could be to other way it could work. Not impossible, just a lot of low-level code monitoring messages to the printer process thread.

2) The easy option - if the system uses a print server - or you can get one set up - the server should be able to send you a simple netmessage when your job is finished. This is going to depend on the capabilities of the print driver but I would be inclined to investigate this option.

TonyJollans
08-19-2005, 04:06 AM
Like others here, I don't know for sure but I would tend to agree that the short answer is no, at least in the general case.

If you use a print server, for example, you could switch your machine off before physical printing ever starts. And as has already been said, once the document (or the last part of the document) is in printer RAM the host machine has no more interest in or control over the print job.

Printers can and do, though, send messages to their hosts if they are, say, out of ink or paper and it may well be that they also send one (or could be configured to send one) when a print job has finished although I don't know if they can necessarily put a time on such a message.

However the question is not about the general case, it is about a specific situation when doing performance tests. The start time is known by your code - all it needs is for someone to press a key when the final page has printed for it to be able to calculate the total time and in this situation I would say that, given all the other factors which can affect performance, if reasonable human response time introduces too much error then there isn't really a significant performance edge in either option.

On a related note, I would also advise against hand-coding lots of complex PCL macros unless there really is an expectation of very significant gain, because the big downside is maintainability - it is a rare skill.

Sir Babydum GBE
08-19-2005, 04:21 AM
Yeah.. I was using a stopwatch earlier.. but I found that there was much room for error with it.. :(How? :bug:

fumei
08-19-2005, 08:58 AM
Hmmmmmmmm.

........no.


As has been stated, Word just hands it over and says bye-bye. It may be possible to time it with some scripting, but the only way I could see (and i am not a super OS scripting guy) that it would work is by interferring with the process. You would have to write something that notes the time - not just when the data is spolled OUT of Word, but when the data is used by spoolsv.exe. As has been mentioned, this script would check every 100 ms or so, to see what is happening.

This is counter productive it seems. Any checking takes time away from the actual job.

If it is difficult to accurately measure the difference with a stop watch....I would suggest there are more important things to be dealt with.

sponge
08-19-2005, 08:33 PM
http://www.qualitylogic.com/genoa_test_tools/performance/pagesense.html

The above site is where I got the idea from. That seems to use some sort of device though for "timing" :(

Ah well... thanks for all the input on this...

I've gone ahead with using a stopwatch (which ended up being pretty reasonable, as I came up with what I thought was a surprising result:

PS3 was always faster than PCL6 with all of the tests I did (through Word - the tests varied by font and image types). This surprised me - I read that PCL would usually be faster in a Windows OS.. maybe times have changed? or maybe what I read was wrong.