FileMaker Extra: Building Your Own Next and Previous Page Buttons

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 move from record to record, as it does for Form views, it performs Next Page/Previous Page navigation, jumping by either 5 records (for list view) or 20 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're viewing records 20 “24 of a set of 24 records and you and click Next, what happens?

It turns out that you don't 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're viewing records 20 “24 of 24 found, and you try to jump to record 25, you end up on a page consisting only of record 24. It's not the end of the world, but it's 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't do anything at all.

You can create different scripts for the Next and Previous buttons, and you can hardcode the jump size to either 5 or 20 depending on whether it's a list or table view, but 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 would use the following formula:

 Let ( [   curRec = Get ( RecordNumber );   jumpSize =    Case (     Get ( LayoutViewState ) = 1; 5;  // it's in List view     Get ( LayoutViewState ) = 2; 20; // it's in Table view     1) ;    // it's in Form View   direction =    Case (     Get (ScriptParameter) = "Next"; 1;  // jump forwards     Get (ScriptParameter) = "Prev"; -1 );  // jump backwards   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. It's common that the Previous link appears dimmed out when you're on the first page, and that the Next link behaves similarly when you're 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 navigation script above. For the Next link, for instance, you could define an unstored calculation field with the following formula:

 Let ( [   curRec = Get ( RecordNumber );   jumpSize =    Case (     Get ( LayoutViewState ) = 1; 5;  // it's in List view     Get ( LayoutViewState ) = 2; 20; // it's in Table view     1) ;    // it's 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 test whether the new record number would exceed the found count, test instead whether it would be less than one.