Word Automation...Keep print job open

[sdocker]

I am using VFP 9.0 to print a report to a PDF, the first page of which is a merged MSWord document as the first page. The remaing pages are printed using REPORT FORM . . . .

The first page is completed as a separate document, I believe because the print job is automatically closed by MSWord.

Is there a way to keep the print job opemed so the rest of the pages can be added?

Thanks
Sam

 

[Olaf Doschke]

No, you can print two print jobs to a real printer and it results in pages, which you can see as one document, if you like, but you can't print to a single file from two different sources that way.
Look out for a PFD merge to merge the two resulting PDF files. Eg take

http://www.pdfsam.org/

(

http://www.pdfsam.org/uploads/pdfsam-1.1.0-tutorial.pdf)

Bye, Olaf.

 

[Mike Lewis]

Sam,

It's quite likely that your PDF print driver will let you achieve this goal. But you will neeed to check its documentation to find out how.

For example, I use the the Zeon Docucom driver. It has a setting that lets you specify what to do if a file already exists with the same name as the one you are outputting. One of the options is to append the new file to the existing one. So, in this case, I would simply make sure that the second print job has the same output file name as the first, and then specify that setting immediately before printing the second job.

But that's just an example. Different drivers work in different ways. So check the features that are available in yours. If no such features exist, shop around for a different driver.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[sdocker]

Mike,
Sounds like the way to go. I will try it and get back.

Sam

 

[JRB-Bldr]

The other way would be to print ALL pages using a single VFP Report Form and outputting it to the PDF print driver document.

I assume that your first page is dramatically different than the subsequent pages. That's OK.

You can make 2 separate VFP Report Forms and then use Print When expressions to control which one to print when. Then finally over-lay the 2 Report Form objects into a single Report Form and use it.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

The other way would be to print ALL pages using a single VFP Report Form and outputting it to the PDF print driver document.

I agree that that's a good general approach. But would it work in this case, given that the first document is a Word mailmerge job rather than a VFP report?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

What I am proposing would be to NOT use a Word Mailmerge as the first page of the over-all document, but instead use a VFP Report Form for the first page.

There isn't much that a Word Mailmerge can do that a VFP Report Form can't do.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Indeed it's not so easy to replace Word Mailmerge. On the other side, if the data for the Mailmerge comes from DBFs, it would also be possible to print a FRX cover sheet with a seperate FRX. You don't need to overdo with PrintWhen, you can REPORT FORM ... NOPAGEEJECT and continue printing the rest. This IS actually keeping the printjob open, but the initial printjob then also is from the same VFP process.

I have to look into Zeon Docucom, if that allows a new printjob on the same PDF output file to append, that's also a fine solution, without fiddling with print jobs and queues.

In legacy Foxpro you had PRINTJOB...ENDPRINTJOB, _PSCODE and more, but that doesn't apply, if Word comes into play and if Windows printer drivers come into play, that applkies to low level printer addressing, which is not possible with PDF printer drivers, as they are per se Windows Printer drivers and not giving you direct control.

I did address a commodore needle printer from a C64 via print codes ESC+something by the handbook. You don't get such handbook printer codes nowadays, besides perhaps for special POS system printers. Printing is done via GDI nowadays, or Postscript. That's the disadvantage, but who wants to code a printe driver like software to be able to print?

I still also see pdfsam as a viable option, because it is more versatile than merging PDFs via printjobs, it could allow you to merge any PDFs (or split them) in other cases, too. I haven't tried it, but it seems a popular software of that kind of PDF mergers in sourceforge ratings. The console version should be good for its automation, sisply via RUN with command line options.

Bye, Olaf.

 

[sdocker]

Thanks for all the suggestions.

The first page is a MSWord merged document that is user designed, so I can't use the report writer.

Mike Lewis's idea seems to be working. The driver I am using has a "MergeFile" setting. If it's value is an existing PDF file, that file is merged with the current "output" document. There is also a "MergePosition" setting for "top" or "bottom".

It involoves a bit of manipulating the filenames, but that is not too difficult. All in all, this seems to be a good solution.

Thanks again ! ! !

Sam