There is an unresolved discrepancy in the evaluation of the current record number in different layout parts. In the footer and the title footer of a multi-page document, the merge symbol {{RecordNumber}} and the Get(RecordNumber) function produce a different result.
The record number that is returned should be the same, regardless of how it is accessed.
I've attached a file that shows this problem in action.
GetRecordNumber.fmp12.zip (91.7 KB)
You are evaluating the same variablename during rendering for each individual record for the preview.
After playing a little with viewsizes, I think the following is happening when entering preview:
The preview is built record by record and then page by page, thus when page 1 is ready the current record at that moment is #31 (where the last visible record is #30)
Hence the value in the titlefooter is the value of the first invisible record, because first FM determined that record #31 would not be visible and after that starts rendering the closing part of page 1 with 30 records. I think that this is intended behaviour.
Does that make sense?
Yeah I think this is right. While I don't know 100% what is going on with the specific timing of the evaluation of each of these methods, the issue is to do with the way the body part is split across multiple pages.
In the body setup the option to allow the part to break across page boundaries is disabled. So this means for record 31 it is half on page 1 and half on page 2. Preview mode determines thus that it needs to be put onto page 2 and not page 1.
The way in which {{RecordNumber}} is evaluating is likely to be based on some slightly different means than the hide condition (which is record by record incrementing based on visibility).
So lets assume the 2 different methods of evaluating, {{RecordNumber}} is likely to be just evaluating not based on preview-mode visibility, but rather the # of total records on the page (including partials) prior to that partial record 31 being chopped off onto page 2 by the preview mode rendering engine.
Your incremental hide calc to populate however must be evaluated after the point at which record 31 is chopped off and put onto page 2, hence why it only hits 30.
To confirm the issue is this, just turn on the option to allow a part to break across boundaries. T his puts part of record 31 on first and second page, and you'll see that the record counters for both methods now match up.
Yes. It's an excellent explanation of what I am seeing. @weetbicks has put some more detail into it but I think you are both describing the same thing.
Both explanations make a lot of sense. I'll link to this thread in the product report. That will give the engineers a head-start on finding a solution. 