PageCount not correct - V11.2.17.1025

[Steven]

Hello,

 

We've got a problem with the PageCount property over here. Most of the time it works (always but once...), So it seems like the pagecount has a bug?

Is there a known bug at the moment?

Our scenario is:

We've got 6 pages, but the PageCount was 5. Pagenumbering works like fine.

It happens only when there is a certain amount of data on the pages, so when I had less data, the PageCount was 6, so correct.

Any ideas?

 

Steven

[Katia]

Hello Steven,

There was an known issue with PageCount not being exported correctly from Silverlight report viewer which was fixed in R2 2017 release.

What rendering format/report viewer are you using and what version of the product?


Regards,
Katia
Progress Telerik

[Steven]

We use nuget package: Telerik Reporting R3 2017 SP1 (version 11.2.17.1025)

XML in the database has schema: http://schemas.telerik.com/reporting/2017/3.0

Was this what u meant?

[Katia]

Hi Steven,

The known issue I mentioned in the first post was fixed in R2 2017 release. You seem to be using a newer version, therefore, this should be a different issue happening on your side.

As I am not aware of any other issues related to the PageCount, it would be necessary to test a sample application that reproduces the problem. You can send it to us in a support ticket.


Regards,
Katia
Progress Telerik

[Steven]

UPDATE:

 

I found out that:

The pagecount went wrong when the footer was kinda big AND not visible on every page. 
I had an expression to show it only on the first and last page. (pagefooter). When I Always set the footer visible, it works.

So thatsthe bug :-) => (big) pagefooter visible = false, expression set is to visible is true => pagecount is wrong

Steven

[Todor]

Hello Steven,

I managed to reproduce the problem only when using the expression PageNumber = PageCount to hide the PageFooter on the last page.
This is a corner case that is due to a known limitation in the paging logic.

Let me explain:
The resulting page count depends on the visibility of the page footer section as this changes the available space for the rest of the report content. In the same time, we setup the visibility of the page section to depend on the page count. This leads to uncertainty. This situation has no solution.

Here is an attempt to explain this in more details:
To know the PageCount that will be generated, the Reporting Engine needs to count the pages first. By default the PageFooter is available only on the first page, and on a page which is initially not known, since PageNumber = PageCount cannot be evaluated (PageCount is not known). When the engine reaches the page that will be the last, it is not aware that it has reached the last page, hence assumes it will have NO PageFooter (by default it is NOT Visible), and calculates that the final content of the report will fit on this page (without PageFooter). Thus, the engine evaluates that the current page will be the last one. At this point the PageCount is set to the current PageNumber.
When the real rendering starts, everything goes correctly until the last page is reached. However, now PageCount is known and the engine has to put a PageFooter on it. Due to the big PageFooter, the entire content does NOT fit on a single page, hence part of the content needs to be moved to another (extra) page. This extra page will have PageNumber = (PageCount + 1), as observed.
Note that this is a limitation of the processing algorithm, not a bug. With a PageFooter that is too big to fit together with the normal page content on a single page, part of the (detail) page content should be moved to another page. There is no point to move only the PageFooter to another page as PageFooter is meaningless without page content. In this case the PageFooter will actually be on the page preceding the last one.

The workaround is to set the PageFooter as Visible only on the first page, and use a ReportFooter that will be displayed by default only on the last page.
If the number of pages is known you can alternatively hard code this value instead of PageCount, i.e. use PageNumber = PreviouslyKnownPageCount.

Regards,
Todor
Progress Telerik