Hi All,
I'm using TWordApplication and TWordDocument components to open a Word
document, populate some bookmarks, save the populated doc with a new
name and optionally print the new document. The relevant bit of code is
approximately like this:
8< ----------------------------------------
uses
..., OleServer;
...
WA: TWordApplication;
WD: TWordDocument;
SaveChanges: OleVariant;
...
try
... open a document, connect to WA, WD, etc
... insert the data
... save document with new name ...
// The uses sets the checkbox cxPrint to get a paper copy:
if cxPrint.Checked then WD.PrintOut;
finally
SaveChanges := wdDoNotSaveChanges; // don't change the original
document
WD.Close(SaveChanges);
WA.Quit(SaveChanges);
WA.Disconnect;
end;
8< ----------------------------------------
This works well with no problems on small, mostly text documents, but
some of the documents I need to print are long and stuffed with
graphics; in these cases, everything works except the PrintOut command
which sometimes seems to be ignored completely, sometimes nakes the
printer blink (but not print anything) and sometimes causes a corrupt or
partial printout.
I *think* what is happening is that if the machine is busy - or it's a
complicated document - the WD.Close and WA.Quit are executed before
Windows gets around to finishing sending the job to the print queue and
the job is cancelled. If I put a delay before the 'finally' block (eg
asking the user to click OK when the print has finished) it works fine.
There is a nice component from CodeCentral called SpyPrinter by Peter
Below which shows how to monitor the printer queue and I have used that
to delay executing the 'finally' block until the print job has a 'job
completed' status. This also works OK, but both of these 'fixes' hold
everything up while the document is being processed. Ideally the user
shouldn't have to wait until the printer has actually finished printing
the paper. I hoped that just waiting until the job status was 'job
started' would be enough - but no.
I could put the printing in a separate thread (not that I am expert in
multithreaded apps) but it is still possible that the user might want to
generate a few documents, then shut down and go home once the jobs are
in the print queue. The printer could be off-line, out of paper ...
well, you get the picture.
So (eventually) my questions: Am I on the right track? If so, does
anyone know how to detect when Windows has finished processing the
document for printing and it is safe to close it?
As usual, many thanks in advance.
Rob Cameron
--
Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: 19/01/2006
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi