Runtime or Not?

[bcooney]

This is a bit of a long story; pls bear with me bcs I need advice and I want to be sure I've explained the entire set of requirements before you, hopefully, offer your opinion.

The system I'm developing for commericial distribution has a specific requirement: the ability to reprint reports anytime and have the content be identical to the first printout. Before a user prints a report, they are presented with a "report configuration" screen that lets them assemble what to include/exclude from the report's content. So, recreating this same report in the future would require not only saving copies of the data as of report date, but also these config settings. Enter Save as PDF.

Ah, Save as PDF is a wonderful feature. Now I don't have to store mountains of data or report config settings. Simply save the PDF into a container field, name it with the report date, and display it in a portal of reports. Only one problem, doesn't work in runtimes.

So, either back to the method of saving all data and settings, or investigate alt methods of creating PDFs. Thanks to this board, I've looked and have working on WinXP/FM8Adv (but not yet tested runtime) Bullzip's PDF printer. It's OK, but I feel like I'm on a slippery slope. I want to support both platforms, and now I have to script both separately.

I'm starting to wonder: perhaps I should simply suggest that we ship an FM8 file and bundle FM8 with it. Why not? Now I've got my Save as PDF back and we open the door to multi-user site packages.

OK. So that's most of the story. The other factors that are encouraging me to keep this as simple as possible is that we require copy-protection (perhaps B. Dunning's Easy Encrypt) and we'll need to update end users (so I have installer and import/export fun in my future).

Opinions? Comments? Please!

[Søren Dyhr]

Ah, Save as PDF is a wonderful feature. Now I don't have to store mountains of data or report config settings. Simply save the PDF into a container field, name it with the report date, and display it in a portal of reports. Only one problem, doesn't work in runtimes.

But in preview do you, no matter if it's a runtime or a full version, have the ability to make a "Copy" and paste it into a containerfield - just make sure to store the clipboards contents just before these scriptsteps and then restore the users clipboard again after stuffing the image of the report in the containerfield.

--sd

[bcooney]

Oh, that is a classic technique (used to use this to give users buttons in "preview mode." However, I believe it only captures the page that you are viewing in Preview. This is--with all options selected--a fifty or so page report. Thanks anyway for helping me to think outside the box.

By the way, Bullzip works great in WinXP runtime.

[Reed]

For the OS X runtime, you can just use the MacOS built-in pdf creation, so you don't need a plugin on that platform.

[bcooney]

I've gathered that it's different on Mac. How do I control the file name and directory in which the pdf is created on the Mac? I will insert the file into a container after it's created.

Bullzip has a hard-coded path/filename in its settings file. I don't care if each pdf file has the exact same name, since it will be stored in a table of pdfs, keyed by id and have a field for the "title" which is unique that the user will use for finding.

[Razumovsky]

This is--with all options selected--a fifty or so page report.

A native, but perhaps clunky, approach could be Soren's suggestion with a related "Report Storage" table and Loop script, one record per page.

I suppose you could have a 50 page long print layout as well...

-Raz

[Fenton]

On a Mac pre-version 8, and runtimes, you would, as Reed said, use the built-in Print to PDF; it's a option in the regular Print dialog for any application. You'd could print to a fixed name file, then rename it using AppleScript. This is pretty easy.

tell application "FileMaker Pro Advanced"

-- above tell line not needed if run in FileMaker Perform AppleScript step

set new_name to cell "Prospect ID" of current record

set file_path to ((path to desktop as string) & "Quotes:temp_quote.pdf")

set newFile to ((path to desktop as string) & "Quotes:" & new_name & ".pdf")

tell application "Finder"

try

if not (exists file newFile) then

set name of document file file_path to (new_name & ".pdf")

end if

end try

end tell

end tell

Søren's solution also works, and is less fragile; there are no external files to keep track of. It is true that you start off on the 1st page. But you can script the page#, and use Go To Record/Request/Page [by calculation] to copy/paste successive pages. Your container field would have enough repetitions to hold the report. One or the other has margins, but not both.

This is going to produce one bloated table however. I'd keep it as a separate related file.

[comment]

In versions 7 and 8, copy in Preview mode produces a bitmap image at screen resolution - so I wouldn't recommend this.

[bcooney]

I don't intend to go the Preview/copy route, but thanks for the suggestions.

I'm debating BullZip and Mac's builtin PDF and shipping a runtime.

[bcooney]

If anyone is interested, I totally abandoned any PDF. I save the contents of the text fields that were created when the report is run into another table "Saved Reports". This way, all in FM, the user can see previous reports.

[Gort]

OK!! so how do you make a 50 page layout that will print out to .pdf or HC in runtime?

I have asked this quetsion previously but no one answered it.

solution appreciated

Tony