How to print: Page y of X ?

[ML2008]

How can I print the page number of total pages at the bottom of reports?

Example: Page 1 of 16

[Genx]

You'd have to freeze the window, go to record/request/page[last], use Get(PageNumber) and store it in a global field called MaxPages or something.

Then make a calculation field to be "Page " & Get(PageNumber) & " of " & Table::MaxPages.

Alternatively, simply use an unstored calc to retrieve Get(PageNumber) then use merge fields:

Page <> of <>

Tedious i know, but it's a bit of a FileMaker short coming.

P.s. i think it's page x of y :)

[SteveB]

Genx means go into Preview mode, not Freeze Window.

Steve

[Genx]

Why yes i do. Thanks steve, though freeze window after entering preview mode so as not to show all the page jumping - then when done, refresh window.

[NRT.Rob]

This is a nice workaround, but I found a problem with it; If you have a footer or trailing grand summary, it appears that your last record can still be on Page 1, for example, with the final subtotals or whatever you have in the trailing summary printing on page two.

Then your display says Page 1 of 1 and then Page 2 of 1. argh!

Is there a more solid way to handle this? Drives me nuts, this should be such a simple operation...

[comment]

It shouldn't matter what page your last record is on. You go into Preview mode, go to the last page, and store the current page number into a global. The page number of the last PAGE (as opposed to RECORD) is the total number of pages.

[NRT.Rob]

Ah, got it. went to last record in browse mode, so it wasn't going to last PAGE. Thank you!!

[amigotto]

We're at version 11 of Filemaker! There is no excuse for this not being implemented in a program of this calibre.

How do we get Filemaker to include this as an option in New Report/Layout? It can do summaries and grand totals and a whole slew of good stuff, but simple total pages...?

[amigotto]

Here's a simpler solution that works very well (I think). But it still would be better for Filemaker to do this automatically (because I'm going to have to add this to all my print layouts manually!)

Create a "total_pages" field (global, number). Place in footer of layout.

Create a Total Pages script:

Enter Prieview Mode []

Go to Record/Request/Page [last]

Set Field [Tablename::total_pages; Get (PageNumber)]

Go to Record/Request/Page [first]

In Layout Setup:

Go to Script Triggers

1 - Select OnLayoutEnter

2 - Select "Total Pages" Script

3 - Enable in Preview

Cheers,

Alvise

[amigotto]

Oops - in Layout Setup, enable in Browse AND Preview modes!

[efen]

How is that way simpler?

[amigotto]

"Simpler" may not be the best choice of word.

Maybe more "flexible", because you don't have to rely on a script that will work on the layout before you select it. I have many buttons that are "goto layout" buttons, or I'll often choose a layout from the layout menu. Just choosing the layout will add the correct total number of pages, independantly of how you arrive at the layout.

In addition, I'll often just want to look at a layout then work on the found set some more before printing to make sure I have the correct records, etc. This solution seems more "flexible" for that. I'll also admit the other way is more cumbersome to implement at least for me.

[comment]

"I'll often just want to look at a layout then work on the found set some more before printing to make sure I have the correct records

So on entering the layout you may have 32 records which require 3 pages. Then you omit 3 records, and print a report of 2 pages with "page x of 3".

[amigotto]

Nope. I don't use the report or print layouts to edit records or find or refine found sets. I do that in form layouts.

Switch to the form, edit records and found sets then preview or print. Repeat until the report contains the exact info I want, with the right number of pages every time. If everything is right except the page count, just move out of the layout and back in and your done.

It IS still a work around though. Filemaker should get their act together and fix it in the software...

[LaRetta]

With vs. 11, no need for global field or calculation ... you can use layout-level variable. Type this in footer: Page ## of <<$$pgTotal>>

At beginning of your preview, perform your steps to grab the last page as many have shown above (after entering Preview Mode)

Go To Record/Requst/Page [ Last ]

Set Variable [ $$pgTotal ; Get ( PageNumber ) ]

Go To Record/REquest/Page [ First ]

Edited July 21, 2010 by Guest

[Vaughan]

There is a reason that no last page number is automatically generated: if there is a large data set with summary fields it requires all the data to be loaded for the sorts, then processed for the calculations, then everything rendered in the printer driver to calculate the last page. It can cause a long wait (literally minutes).

I've removed last page number calculations from some complex reports I've worked on because it caused a huge wait for the client who just wanted a quick peek at the summary and not actually print.

[amigotto]

I was hoping someone would say that! I've only recently began working with v11 and haven't gone through the documentation yet.

It would be nice to be able to add layout variables from the Layouts menu - New Layout/Report though, in the headers and footers options. But I guess that would mean there would have to be an extra step for including the script trigger as well.

Does this resolve the slowdown for large databases with calculation fields? With the calc field and a report with about 20.000 records (8-10 fields including summaries, grand totals, etc.), 1.132 pages, I notice only a very very slight delay (milliseconds) in generating the report compared to the layout variable solution, which seems almost instantaneous.

[LaRetta]

Speed if deciding whether to preview for printing is another issue. When you want page # of ## then we currently need to go to the last page in preview mode. Using a variable will save having a field called gPgTotal.

But yes, using layout-level variables can save creating a lot of calculations which would speed up your solution as well as saving you wading through a lot of fields. This can be burdeonsome particularly when working with external sources, such as MySQL. It would be nice if we could truly separate the calculations from the data but that isn't totally possible (even with separation model).

Anyway, layout-level (self-firing) variables rock. If you doubt, check out some of the work by Mr_Vodka, Comment and BruceR (one example of the self-firing variables is Hierarchical Portals (one of those sleepers where most people miss the power of it).

PS - when viewing the link I suggested, take a good hard look at the "I declare variables" text field. I am incorporating that concept throughout my work.

Edited July 21, 2010 by Guest