[Pages] not returning correct count

[terri]

My application uses the Access 2000 Runtime.

Reports include [Page] of [Pages] in the page footers. In many instances
there is a discrepancy in the total page count. I am finding two different
issues with the report preview:

1 – Sometimes I am simply not getting an accurate [Pages] count -- 1 page is
displayed and 1 page physically prints, yet [Page] of [Pages] displays 1 of 2.

2 – Sometimes the preview is not paginated the same as the actual print
output -- 14 pages display on screen, but the physical print outputs 12 pages
(that page break differently from the preview) and the printed footer
displays x of 14.

Both issues only happen sporadically -- feeding the same report a different
queried data set may result in the preview/print and [Pages] count all being
perfectly in synch.

Any ideas?

 

[terri]

Thanks for responding Marshall.

In the 12 of 14 pages example I am doing a lot of manipulation in Format
events to prevent an endless loop when the section Keep Together is Yes
(required) and a memo field is too big to fit on one page. It does
increment/decrement variables across records to keep track of section
heights to calculate available page space…

However, the Page 1 of 2 example is a pretty simple list with a single group
(Keep Together is With First Detail). I do save the [Page] value to a module
variable in the Print event and compare it to the [Page] value in the detail
Format event to make certain controls visible/invisible. But all records
print something, and there are no section visibility toggles.

From your response, am I to assume that I can’t rely on the value of [Page]
OR variables incremented across records???

--
terri

My application uses the Access 2000 Runtime.

Reports include [Page] of [Pages] in the page footers. In many instances
there is a discrepancy in the total page count. I am finding two different
issues with the report preview:

1 – Sometimes I am simply not getting an accurate [Pages] count -- 1 page is
displayed and 1 page physically prints, yet [Page] of [Pages] displays 1 of 2.

2 – Sometimes the preview is not paginated the same as the actual print
output -- 14 pages display on screen, but the physical print outputs 12 pages
(that page break differently from the preview) and the printed footer
displays x of 14.

Both issues only happen sporadically -- feeding the same report a different
queried data set may result in the preview/print and [Pages] count all being
perfectly in synch.

That kind of thing usually happens when you use code to make
a page break control or a section visible/invisible
depending on the page number or a value your code
accumulates across multiple records.

 

[terri]

I didn't know Me.Top would return the section position on the page... this
should eliminate the need for the incrementing/decrementing variables I am
doing now to calculate the "used" portion of the page.

Thanks again Marshall!
--
terri

In the 12 of 14 pages example I am doing a lot of manipulation in Format
events to prevent an endless loop when the section Keep Together is Yes
(required) and a memo field is too big to fit on one page. It does
increment/decrement variables across records to keep track of section
heights to calculate available page space…

However, the Page 1 of 2 example is a pretty simple list with a single group
(Keep Together is With First Detail). I do save the [Page] value to a module
variable in the Print event and compare it to the [Page] value in the detail
Format event to make certain controls visible/invisible. But all records
print something, and there are no section visibility toggles.

From your response, am I to assume that I can’t rely on the value of [Page]
OR variables incremented across records???

You can rely on the value of Page and Pages. However, Pages
is a very complicated thing that you can mess up by doing
things in strange ways.

OTOH, you can not accumulate values across multiple records
because report section are not necessarily processed in any
particular order. Things like Pages, KeepTogether and even
previewing require the ability to back up and do some or all
of the report multiple times. The Retreat event was
originally intended to help you keep track of this stuff,
but the situation is too complex and the event is for all
practical purposes useless.

If you need to know where a section is on the page, use
Me.Top (vertical) or Me.Left (horizontal).

If you want to count details or accumulate a value, use a
text box with its RunningSum property set to Over Group.