Thursday, March 8, 2012

Absolutely page-bottom alignment on "report footer": Impossible?

Relative newb to SSRS here, but the answer to this question evades me; answers and insight are appreciated.

Report in question is an invoice form. It requires an absolutely bottom-of-page aligned footer that has databound elements.

This is so that whatever page that footer finally appears on will print in such a way that the address will align in a windowed envelope.

Ironically, Books Online gives this exact scenario in explaining headers and footers in SSRS, but they cleverly don't explain how an absolutely bottom-of-page-aligned and data-bound footer can be made to happen. Headers at absolute page top is obviously no problem. Footers at page bottom, not so much.

So, this is not a "page footer"--page footers are employed in the body. Also this footer is databound, so a page footer as it's known in SSRS is out the window anyway.

Most of the time this will print on a single page, but if it breaks to multiple pages, that footer needs to go all the way to the absolute bottom.

I grasp that the "report footer" for SSRS is just what appears at the end of any repeating controls that you've implemented in your body. Because SSRS uses this kind of repeating-control based idiom rather than a section-based idiom as Crystal does, this kind of (what I would consider very basic) positioning control is looking fairly impossible right now.

Among what I've tried:

--Page footer (can't; databound)

--Specifying a page break after the pre-footer controls, and/or a page break before the controls that make up the footer in their properties. This leads to unpredictable results with blank printed pages (as many as 8 for what previews as a 2-page report, how silly is that?).

--Putting in a page-height rectangle as part of the footer (with and without the page breaks mentioned above), with the idea of forcing a basically blank page at the end of the report so that the footer will go to the bottom. SSRS will go ahead and break the page anyway on long elements like that, which again leads to the "footer" being printed in the middle or top of the final page, or whereever it happens to fall.

I may be having to explain to my client that you can't get there from here, and they may have to redesign their report. Does anyone have any insight?

Thank you for your time in reading this.

Hi there Matty,

I think i got the idea that you want to print out the address of the customer at the bottom of the page (ideally the report page footer) but it won't allow you to have any databound values because the databound values are only for the body right ?

If that is the case, there is a common way to get around this.

This is what I do and it does work. Make a couple of textboxes (tb1 and tb2) in the Body of the report. Set the Hidden properties to True for the textboxes.

Next, drag or code into the tb1 and tb2 the dataset values; Name or address or whatever.

In the report footer or page footer, Set your textboxes and named them tbName and tbAddress.

in the expression builder for tbname, put this "=ReportItems!tb1.value" and in tbAddress put "=ReportItems!tb2.value"

When you run the report, tb1 and tb2 will be invisible (you can even send them to the back, hiding behind the table or something, but always make sure that the Hidden property = true). yet your page footer should have the values assigned to them.

I hope this helps and is according to what you are trying to describe.

Bernard Ong

|||

Kind of. The method you describe is pretty much what Books Online says about it. Key to the problem here is that this footer should only appear on the last page, which you get around by examining the page number using hidden fields as you describe, then making it visible as needed.

Problem is, though, that SSRS appears to 'reserve' the space for the header or footer whether it's visible or not, or you've specified Print On Last Page/First Page or not. It just doesn't render elements in that region but it does save the space.

This particular "footer" is literally 1/3 of a portrait page, so I can't have that kind of blank space being held on pages where it's not in use. I've also noticed issues in preview when you have invisible elements in use; although it'll print OK, the display is wildly off.

Very much appreciate your response, though. If you had a workaround up your sleeve for these additional issues with that method, then I'd be golden! :D

|||

As you said, set PrintOnLastPage=true for page footer and then use top padding to print it at the bottom of the page. You can also use expression to set the passing.

Shyam

|||Thank you, but unfortunately that also does not address the space reservation noted above that is critical to this particular use case. Use of the page footer here as the report footer denies it from a differently-formatted use in the report body when it spans pages, and it also causes the space to be reserved on the body pages; this particular report cannot use just 2/3s of the page on every page besides the last one.|||

I too have a business requirement to put 'footers at the bottom' and have found (like a lot of others here) that SSRS doesn't make this easy using the built-in footer section. The real show stopper is that once you declare the size of the footer section at design time, that's what you get on each and every page.

The breakthrough for me was to recognize that footers as I needed them are really report content. When I took that approach, it became a solvable problem involving three items: the preceding content, the offset, and the notes (as I call them so as not to be confused with SSRS footers).

The offset is implemented as a subreport that has an invisible, variable length table. The length of the table is determined by a parameter, cleverly called the 'offset'. The invisible table acts as filler between the preceding content and the notes so that the notes are bottom justified.

The report gets the offset parameter by calling into business logic that uses:

the data for the preceding content,

the data for the notes content,

the page layout, and

the starting position of the preceding content

No comments:

Post a Comment