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

Reply via email to