A few years back I did an article on producing a PDF catalog + table of contents, with the TOC based on a vendor table and the catalog entries based on a products table. Today we’re going to use a different approach to generate a table of contents, building on techniques explored in last year’s Virtual List Reporting series… specifically we’re going to generate one big PDF combining nine reports, prefaced by a table of contents.
To avoid repetition, today’s article assumes basic familiarity with the virtual list technique (see Virtual List Reporting, part 1 for a general intro, as well as details re: reports 2 – 6, and Virtual List Reporting, part 2 for details re: reports 7 – 9).
Our interest today is primarily focused on the “generate master report w/ t.o.c.” script, which creates the TOC, appends each report, and then displays the PDF.
Report 1 is a simple listing of sales this month in the amount of $500 or more, and the main purpose it serves is to force our TOC to accommodate a report with a variable number of pages: possibly 8 or 10 towards the end of the month, but it could have zero pages at the beginning of the month, if there have not yet occurred any sales meeting the $500 minimum threshold… in which case the report won’t be generated, and therefore should not appear on the TOC.
Here’s the TOC in layout mode (based on the virtual list table).
And here’s the virtual list table during TOC generation.
The basic plan:
- Name the report (prompt user via input dialog)
- Get the page count for report #1
(we know page counts for the other reports)
- Generate and output the TOC
- Generate and append the reports
(ensuring correct page numbering)
- Display the PDF
Some general observations about the demo:
1. $$startPage ensures the page number at the bottom of each report page is correct.
2. Rather than monotonously incrementing the page numbers and calling “report 1”, “report 2”, etc. nine separate times, we use a loop to increment page numbers and invoke the reports via OpenURL — this little trick effectively gives us “perform script by name” capability.
This demo is identical to “v1” except the hard-coded script names in v1 seem awfully brittle, don’t they? What if we dynamically invoke those scripts by ID instead of by name? Well, we can’t do so directly, but we can do the next best thing: we can detect and store the IDs, and then translate the IDs back into script names (which can be called dynamically) at run time.
We detect the IDs using a variant on FabriceNordmann’s FMNameID custom function, FMNameID_Script, like so…
…(for more info, see this article: Avoiding Brittleness). The script IDs are loaded into a $var when the master report runs…
…and then the ids are translated back to script names at run time.
The benefit of course being that in demo 2 the “report” scripts can be renamed without breaking the master generation routine.
#1. Once again, a huge thank you to Bruce Robertson for inventing virtual list and sharing it with the FileMaker community.
#2. Now that we have a table of contents for our master report, wouldn’t it be nice if we could hyperlink each TOC entry to its corresponding report within the PDF?