FileMaker Extra: Building Your Own Next and Previous Page Buttons

When a user views records via a browser as a list or table, the flipbook navigation tool in the status area changes its behavior slightly. Rather than moving from record to record, as it does for Form views, it performs Next Page/Previous Page navigation, jumping by either 25 records (for List view) or 50 records (for Table view). If you have hidden the status area from your users, you need to create your own Next Page/Previous Page buttons and place them in the header or footer part.

The concept is fairly simple: You need a script that jumps ahead or backward by some number of records. One thing you need to consider, however, is what should happen when the user is already on the first or last page. That is, if you are on record 1 and try to go backward, what happens? And, if you e viewing records 2650 of a set of 50 records and you and click Next, what happens?

It turns out that you don need to worry too much about the first case. If you feed the Go To Record/Request/Page script step a negative number or 0, you simply end up on record 1, which is perfectly acceptable behavior. However, in the latter case, if you e viewing records 2650 of 50 found, and you try to jump to record 51, you end up on a page consisting only of record 50. Its not the end of the world, but its also not what users expect. It would be better if the Next Page script were smart enough to know when it would exceed the record count, in which case it shouldn do anything at all.

You can create different scripts for the Next and Previous buttons, and you can hard-code the jump size to either 25 or 50 depending on whether its a List or Table view. You can also use script parameters and conditional logic to do everything, including the check for exceeding the found count, in a single, one-line script. That step would be Go To Record/Request/Page [By Calculation], and it would use the following formula:

Let ( [
 curRec = Get ( RecordNumber );
 jumpSize =
 Case (
 Get ( LayoutViewState ) = 1; 25; // its in List view
 Get ( LayoutViewState ) = 2; 50; // its in Table view
 1) ; // its in Form View
 direction =
 Case (
 Get (ScriptParameter) = "Next"; 1; // jump forward
 Get (ScriptParameter) = "Prev"; -1 ); // jump backward
 newRec = curRec + (jumpSize * direction) ] ;

 Case ( newRec > Get ( FoundCount ) ; curRec ; newRec)
)

You might want to add one other finishing touch to your Next and Previous buttons. Its common that the Previous link appears dimmed out when you e on the first page, and that the Next link behaves similarly when you e on the last page. One way to accomplish this is to use the TextColor function to conditionally gray out the link text in those situations. The logic needed is virtually the same as in the preceding navigation script. For the Next link, for instance, you could define an unstored calculation field with the following formula:

[View full width]
Let ( [
 curRec = Get ( RecordNumber );
 jumpSize =
 Case (
 Get ( LayoutViewState ) = 1; 25; // its in List view
 Get ( LayoutViewState ) = 2; 50; // its in Table view
 1) ; // its in Form view
 newRec = curRec + (jumpSize ) ] ;
 Case ( newRec > Get ( FoundCount ); TextColor ("Next"; RGB (120;120;120)); TextColor 
("Next"; 0))
)

You can simply place this field in the header and define it to be a button, or you can place it on top of a graphic element to make it look like a button. If you do the latter, you need to be sure to group the two elements as a single button to avoid having them function independently. Do not use Merge fields for the text because calculated text colors in Merge fields do not show up properly via IWP.

The logic for the Previous link is similar. Rather than testing whether the new record number would exceed the found count, instead test whether it would be less than 1.