To automatically save the pdf in a folder

[janak vyas]

Hi !
I wanted to know if it is possible to save the pdf into a folder.
What I mean is, the program will first create a folder and then save the pdf(s) into that particular folder.
folder name being created from a variable.

How is it possible?

 

[Mike Lewis]

Yes, this is possible. But we need to know what method you are using to create the PDF. Every PDF driver or utility has its own way of doing things.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[janak vyas]

We use a printer prompt, which prints using adobe acrobat for creating pdf.

 

[Chris Miller]

Then look into adobe acrobat printer (driver) settings.

Think about it, a PDF printer driver is acting as if it is a printer. And not only VFP, any programming language or also any application capable of printing, will not provide a means to give prints a file name, as they go to paper, usually.

So that has to be solved by printer/driver settings.

Chriss

 

[Mike Lewis]

I haven't got Acrobat installed, so I can't test this. But all printer drivers have a way of specifying the destination of the PDF. Look into the driver's settings. If that doesn't help, check its documentation.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Just glancing at the Adobe docs, I noticed this:

Your PDF is saved in the folder specified by the setting of the Adobe PDF Output Folder in the Preferences dialog box; the default location is My Documents. If you specify Prompt For Adobe PDF Filename, then a Save As dialog opens when you print.

There is more information here:

https://helpx.adobe.com/acrobat/using/using-pdf-printer.html

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ManniB]

You can use

http://www.foxypreviewer.com/

to directly create a pdf from a VFP report and save it to a specific folder without a printer prompt. It's free and has many option as well.

 

[janak vyas]

Yes, Mike. I currently use the default folder wherein the acrobat saves all the pdf.
What I am trying to achieve is for the program to every time create a folder and save all the pdf(s) into that folder, and what I am not able to figure out is, how to tell the Acrobat or any other method to select every time a new folder based on the folder name 'the would be' vfp program will create the name of the folder to save the pdf(s) into.

 

[janak vyas]

@ManniB that is what I am trying to avoid. I print out sets of 10 pdf(s) for 100 companies in one go. What I want the program to do is every time create a folder for the company and save the 10 pdf(s) into that particular company's folder and then move on with creating another folder for another company and save the 10 pdf(s) into that particular folder.

 

[Chris Miller]

It's not easy to influence printer driver settings from VFP. Dialogs are custom to driver manufacturer and there is no common standard or API I know of.
There are things like print job handling, but they also are standards defined long before anyone thought of printer drivers that only act as virtual printers and save files instead of printed pages.

But once you know where PDFs are created, you could write code that takes them from there and moves them where you want them to be.

Chriss

Edit: A sign I'm probably right is googling for auch an API of specifying output names I find a) lots of questions b) lots of answers for specific software.

And all I know about adobe is aside their free reader they take high prices for any service/server, document management related things. On the other side they do offer some OLE classes for use in their commercial software suites. In the end, if you want definite control and no admin or power user reconfiguring output so your own document relocation could be detached, you would need to switch to something giving you better control.

I think what you can do is install the adobe pdf software driver under a specific printer name, configure it and make this a configuration hidden from users or controlled by policies and then are controlling it as best as you can (unless the whole software is deinstalled) or you go the route of taking it into own hands, which foxpreviewer does. It actually uses a library to write out PDF files, not just another of those virtual printers that create PDFs. That's also a reason it is much tighter coupled into VFPs report handling, not only by a report listener but by the app modules.

Another commonly used one that has an OLE configuration class is Bullzip PDF printer. If you're stuck with Adobe you're also stuck with their options.

 

[Mike Lewis]

You could do something like this:

* Create a  PDF for the curent company in Adobe's 
* default directory; assume the directory is c:\pdf;
* Assume the filename is Company1.pdf

* Create a folder for the current company:
MKDIR c:\c1

* Move the PDF from the default folder to the one you just created:
RENAME c:\pdf\Company1.pdf TO c:\c1\Company1.pdf

* Repeat the above for all the other companies

I think that would be quite simple

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Mike, I think when you print the same report with data for several companies, then the difficulty could be that it actually looks like this in Adobes default output dir:

[pre]report1.pdf
report2.pdf
report3.pdf
report4.pdf[/pre]

With no sign of which belongs to what company.

A solution in the direction of moving files is what I also suggest, but in the worst case you don't know which PDF is what. Assume you at least can find the output folder, then a first step before even starting to print is listing all current PDFs, then only process new PDF files that occur after your printing. For clarity of which PDF is caused by which report run only run one report at a time.

In the best case the adobe options offer to make the VFP report name (without its FRX extension) part of the output name, too. So in theory you could control the output file name if you have an FRX you rename to what you need it to be before printing, or create copies of an original FRX and run them.

And then before RENAME you should check when you get exclusive file access, check if FOPEN('some.pdf,12) gives you a >0 handle, then th e print is done and you can move the file. But Mike, I give you that it might not need immediate actions, as aftermath done after all printing you could just do this once all printing is done.

Chriss

 

[Mike Lewis]

Good points, Chris. We really need to know a bit more about the workflow. But if you are right about the way the reports are named (report1.pdf, report2.pdf, etc.), then one solution would be to create each PDF one at a time, then move it to the destination directory, and then to immediately delete it from the source directory. That way, there would only ever be one file in the source directory, and that file would be the one that belongs to the most recent customer processed.

An alternative approach would be look in the source directory for the file with the most recent timestamp. Again, that would be the file belonging to the current customer.

Either way, I wonder if we need a delay between the REPORT FORM command and the commands that do the moving. In other words, is the process of creating the PDF synchronous or asynchronous? Might need a bit of experimenting to find out.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Mike,

you're right, this needs experimenting anyway. I can only imagine a printer driver either creates a file in some temp/working directory and finally copies or moves it to the output directory - so quite similar to what we want to achieve ourselves. Or the other way would be the driver creates a PDF in the output directory and processes on it until the printing finishes.

In both cases the PDF will not be there in an instance, even if a file is copied it's not there in full size immediately. Only a "real" move that actually only changes the TOC record of a file to belong to a new directory means when you detect the file it's there, fully.

What I don't like about the one report at a time idea, even though VFP isn't multi tasking anyway, you might be back after REPORT FORM before the printjob finishes, there's the printer system, spooler and driver involved, so you could have better throughput when you don't need to wait to the point you have moved the result file away.

I can also imagine you could find the company name within the file. You don't have to write a full pdf file parser, I guess you could go for a simple instring search, actually. Then whatever spooler and stuff cause to the output sequence you can assure you're sorting the PDFs correctly.

Chriss

 

[Steve Meyerson]

Another approach. Here's a simplified version of what I think you might want.
I use FoxyPreviewer.app as ManniB suggested.
Assumes 2 tables:
CompanyList.dbf to include FolderName for each company
ReportList.dbf to include ReportName & OutFile (name)

DO FoxyPreviewer.app
SELECT CompanyList  && Fields include FolderName
SCAN
 MKDIR (FolderName)
 SELECT ReportList
 SCAN
  rpName = ReportName
  outFile = ADDBS(TRIM(CompanyList.FolderName)) + ALLTRIM(OutFile)
  REPORT FORM (m.rpName) OBJECT TYPE 10 NEXT 1 NOCONSOLE TO FILE (m.outFile)
 ENDSCAN
ENDSCAN

HTH
Steve

 

[Mike Lewis]

Steve's approach should work well. Just be sure that the output file has a PDF extension, otherwise FoxyPrevewer will consider a text file. Also, the [tt]NEXT 1[/tt] is presumably just there for testing purposes. In practise, Janak, you would probably use a FOR expression to filter the report for each company. But the overall idea looks good.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve Meyerson]

Also, the NEXT 1 is presumably just there for testing purposes..

Thanks, Mike. I failed to mention that. Actually I extracted & edited a small part of my program which has another dbf to which the NEXT 1 applies. As you said, it was only to provide as an "overall" method (which has worked for me many times). Thankful for FoxyPreviewer!

Steve

 

[Chris Miller]

You should mention that the TO FILE clause only works for PDFs in this context, as Foxypreviewer handles creating a PDF itself.

Otherwise it's only good for text file outputs, as Mike says, so you can't use that approach with any PDF printer driver. Which, on the other hand underlines the advantage of using Foxypreviewer to have that output name control. But there might be reasons a company decides to only allow PDFs created by Adobe software.

Chriss

 

[Steve Meyerson]

Hi Chris,
I didn't mention in my app, the TO FILE (m.outFile) contains the .pdf extension in m.outFile. Not sure what would happen if it didn't. Haven't tried that.

I think the OP's files are all pdf's. Not sure why a company would insist on Adobe instead of FoxyPreviewer output. Is there a difference?

Steve

 

[Mike Lewis]

The reason I raised the point about it being treated as text was that, when I tested Steve's code, the output file's extension defaulted to TXT, so naturally I double-clicked on it to open in my text editor, expecting to see the actual data from the report. What I saw was the underlying Postscript code (at least, I think that what it was).

Not a big point. I just wanted to point out the FoxPreviewer defaults the extension to TXT, even though it a genuine PDF.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads