Page Break unwanted

[James Hansell via AccessMonster.com]

Help! I'm working on a report with many text boxes in the detail section.
The boxes are set to shrink if Null, and a total cost calculated from their
values in the last text box. As soon as the number of valid text boxes
touches the bottom limit of the Detail section, a second report page is
created as expected. However, all the text boxes to be added jump to the
second page, leaving a large white space. By giving the boxes data in their
source table one at a time, I can get page 1 to show boxes down to the
bottom of the Detail section, but one more box worth of data causes this
unwanted page break. When I insert a page break at the bottom of the detail
section, and eliminate data, the page 1 textboxes shrink, but the boxes
pushed onto page 2 stay there!

 

[Marshall Barton]

Help! I'm working on a report with many text boxes in the detail section.
The boxes are set to shrink if Null, and a total cost calculated from their
values in the last text box. As soon as the number of valid text boxes
touches the bottom limit of the Detail section, a second report page is
created as expected. However, all the text boxes to be added jump to the
second page, leaving a large white space. By giving the boxes data in their
source table one at a time, I can get page 1 to show boxes down to the
bottom of the Detail section, but one more box worth of data causes this
unwanted page break. When I insert a page break at the bottom of the detail
section, and eliminate data, the page 1 textboxes shrink, but the boxes
pushed onto page 2 stay there!

Not sure I followed all that, but it sounds like you might
have the detail section's KeepTogether property set to Yes.
Try setting it to No and see what happens.

If that's not what the problem is, please provide more
information, especially about any Groups (there is a group
KeepTogether that may also produce this effect).

 

[James Hansell via AccessMonster.com]

Marshall,
The Detail section's Keep Together was set to "NO." My report does not
use Groups, just Report Header on first page and Page Header/Footer on all
other pages.
Page Setup, under Column Size, says width=7", height=7.4993", and the
"Same as Detail" box is checked. Could this have anything to do with it?
The Detail section for this report does not exceed 7" even with the narrow
Page header versus the Report header. In design view, my report's Detail
section is a stack of text boxes that may or may not exist in Print View,
depending on whether their source fields have a value in them. If Null,
they shrink. Their values are totaled in the last text box. The text boxes
extend the Detail section beyond its normal length, but I thought they
would just overlap onto the second page. Instead, when the data would cause
this overlap, Access takes the entire chunk of text boxes and moves them to
page 2. Using horizontal line segments, I found the break point is at
5.6667" down the Detail section. When I insert a page break at the bottom
of the Detail section, the page breaks correctly. Unfortunately, if I
eliminate data that shrink page 1's text boxes, page 2's stay put. One
curious thing: just above where Access chops off the block of text boxes,
there's a hint of leftover pixels, as if it left behind the topmost atoms
of the top text box. Any ideas? I'm at the banging-my-head-on-the-monitor
stage of the Access grief process.....
James

 

[Marshall Barton]

Marshall,
The Detail section's Keep Together was set to "NO." My report does not
use Groups, just Report Header on first page and Page Header/Footer on all
other pages.
Page Setup, under Column Size, says width=7", height=7.4993", and the
"Same as Detail" box is checked. Could this have anything to do with it?
The Detail section for this report does not exceed 7" even with the narrow
Page header versus the Report header. In design view, my report's Detail
section is a stack of text boxes that may or may not exist in Print View,
depending on whether their source fields have a value in them. If Null,
they shrink. Their values are totaled in the last text box. The text boxes
extend the Detail section beyond its normal length, but I thought they
would just overlap onto the second page. Instead, when the data would cause
this overlap, Access takes the entire chunk of text boxes and moves them to
page 2. Using horizontal line segments, I found the break point is at
5.6667" down the Detail section. When I insert a page break at the bottom
of the Detail section, the page breaks correctly. Unfortunately, if I
eliminate data that shrink page 1's text boxes, page 2's stay put. One
curious thing: just above where Access chops off the block of text boxes,
there's a hint of leftover pixels, as if it left behind the topmost atoms
of the top text box. Any ideas? I'm at the banging-my-head-on-the-monitor
stage of the Access grief process.....

This is really confusing ;-(

I'm not at all sure that I am actually reproducing what
you've got, but I think I may have stumbled on something.
If some of my text boxes overlap (top to bottom), then I
seem to get the ones that move to the next page break at a
point where they don't overlap. I suggest that you use snap
to grid to make sure there are no overlapping text boxes or
maybe just leave a tiny amount of white space between the
bottom of each and the top of the next text box.

 

[James Hansell via AccessMonster.com]

Marshall,
I turned on snap-to-grid and made sure the text boxes weren't
overlapping, but the problem still remains.
I did discover one thing. The fraction of Detail section left behind
on page 1 after the unwanted page break exactly equals the height of the
page header. I adjusted the page header up and down, but the page break
didn't shift.

Here's a sample of a typical textbox Control Source setting:

=IIf([MaintSelCallBlk]Is Null,Null,"MRC Selective Call Blocking")

after that is a lone text box that gets the fee from a Maintenance Fee
table. The last text box totals the ones above it.

After doing some math, I determined the maximum size of the detail
section (5.375"), given margins and header/footer height.I inserted a page
break at this measurement and the text boxes move to page 2 correctly in
print view. However, when I delete data that should cause some page 2
textboxes to be pulled back to page 1, they don't move. A white space
appears at the bottom of page 1's Detail section as the textboxes retreat.
James

 

[Marshall Barton]

I turned on snap-to-grid and made sure the text boxes weren't
overlapping, but the problem still remains.
I did discover one thing. The fraction of Detail section left behind
on page 1 after the unwanted page break exactly equals the height of the
page header. I adjusted the page header up and down, but the page break
didn't shift.

Here's a sample of a typical textbox Control Source setting:

=IIf([MaintSelCallBlk]Is Null,Null,"MRC Selective Call Blocking")

after that is a lone text box that gets the fee from a Maintenance Fee
table. The last text box totals the ones above it.

After doing some math, I determined the maximum size of the detail
section (5.375"), given margins and header/footer height.I inserted a page
break at this measurement and the text boxes move to page 2 correctly in
print view. However, when I delete data that should cause some page 2
textboxes to be pulled back to page 1, they don't move. A white space
appears at the bottom of page 1's Detail section as the textboxes retreat.

Sorry James, but until you made me try to get this effet,
I've never seen that problem. In all my attempts to
reproduce the problem, the only anomalous behavior occured
when the controls overlapped (even by the tiniest amount).

Maybe, I wasn't clear enough about what I mean by "overlap".
Any control (label?), even one that is not actually
touching another control can produce this effect if its top
is above the bottom of another control or if its bottom is
below the top of another control. I guess all this makes
some kind of sense, since one or the other would have to be
"split" if one control were to be on one page and the other
on the next page.

If none of this helps you out and if you can strip your mdb
file down to the minimum stuff necessary to demonstrate the
problem, Compact it and then Zip it to less than a megabyte,
then email it to me and I'll take a look at what's going on.

 

[James Hansell via AccessMonster.com]

Marshall,
I tried one last thing and it works now. I de-selected Snap-to-grid
for these shrinkable boxes, and separated every one of them horizontally
and vertically by the smallest space possible. One click of the arrow keys
left a grey area between them, but I separated them one increment more. Now
these non-null textboxes overflow onto page 2 and back like they are
supposed to. Thanks for your help!

James