Jump to content
Server Maintenance This Week. ×

Determine Page Number of Previous Record using GetNthRecord


This topic is 3249 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I need to identify if a record is the first record on a page. I was hoping to use getnthrecord to do so--along with an unstored calc of get (pagenumber) named pageNumberC to determine the page number of the previous record in a report. The formula is getnthrecord ( pageNumberC ; get (record number) - 1).  If this value was less than the current record, I would know that the record is the first on a page.

It appears that get (pagenumber) is fully contextual and does not function with getnthrecord. No matter which record I select, it only shows the current page number. And as far as I know, FM can't write data while in Preview mode, so I can't store which page a record will fall on in the report.

Am I missing something from getnthrecord usage? Any suggestions for accomplishing the goal of determining if a record is the first on a page?

Link to comment
Share on other sites

I have a report where the subsummary section information needs to also always appear in the header if the subsummary section does not begin at the top of the page. The design problem is when a subsummary starts at the top of a page. The solution: hide either the header or subsummary when the subsummary starts at the top of a page.

I found an easy method to hide the header if the subsummary starts at the top, a summary field that restarts counting at subsummary breaks. If the value is 1, hide the header so that only the subsummary appears. HOWEVER, headers don't shrink and the accompanying white space is unacceptable to the client.

That lead me down the road of the second option...hide the subsummary elements and shrink that (since these parts do shrink). Because page number is so contextual, all logical calcs I tried failed on me, and I'm unable to write data to the records in preview mode where page numbers are known. 

Row heights vary, so a simple calc relating to the number of found records won't help.

The need to have the same info in the subsummary part and in the header is non-negotiable, the need to not have this duplicate non-negotiable, and since there's no workaround for shrinking the header, I'm focusing on hiding fields and shrinking the subsummary parts. 

Link to comment
Share on other sites

I am afraid you have managed to confuse me. I think you want to hide layout objects in a (leading) sub-summary part, if the first record of the group is also the first record of the page?  But that could backfire if Filemaker decides to place the sub-summary part at the bottom of the preceding page, could it not?

Link to comment
Share on other sites

Yes, that's it. Thanks for succinctly summarizing. I need to hide layout objects in a leading sub summary part (and shrink that part) if the first record of that part is the first record on a page.

The potential problem you raise is a risk I'm willing to test out if one of us could figure a way to get to that point.

Link to comment
Share on other sites

As I said earlier, it's not a simple task. See here how to determine the page number on which each record is;

Note:

  1. This is a rather old post and it does not account for the possibility of record locking in a multi-user scenario. A better method would write the TOC to a variable or to a global field;
  2. In your particular situation, you could speed things up by omitting multiple records. For example, if the last group has 25 records, omit the last 24 and take note of the page count. Then omit one more record (i.e. the first record of the sorted group); if the page count decreases, then that record is the first record on its page.
Link to comment
Share on other sites

Ha, you're right there, Comment. Thanks so much for sharing that post. The scripting suggested by the post is relatively simple, but the caveats numerous...record locking, time to execute on thousands of items, modifying record dates...and mapping out a more reliable and efficient way of dealing with those, as you've begun to map out, doesn't look pretty at all. Certainly time to stop working and checkin with the client to see if an internal report with these particular design requirements is worth the effort and time. Thanks again!

Link to comment
Share on other sites

This topic is 3249 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.