"How hard can it be?"

Doing it again for RDLCs, which I thought would be a trivial exercise, is turning out to be harder than imagined, for an entirely unexpected reason.

As you also may remember, I wrote some pretty dodgy code in the original walkthrough to handle the fact that page numbers need to be stored and evaluated differently for different renderers (for example, HTML versus PDF). This is because pagination has to be taken care of differently by different renderers, depending on their type of output. In addition to having different physical page layouts to fill, each renderer is also free to handle the pagination and body events in whatever order, with whatever collections, fits their needs. For example, a CSV renderer won't have much use for page header material at all.

I've discussed the differences between formatting and data bands a number of times in this blog and won't belabor that point here.

I should have realized... the renderer for local reports inside report viewer is, again, dealing with a different set of conditions and it seems to evaluate events and repeating items differently too. In hindsight, actually, this should have been the first thing I worried about.

Here's what I'm noticing today: when you're repeating table headers on new pages, a table header expression is not re-evaluated each time it is rendered. (This seems to be true in both the in-viewer representation of the report and the PDF and Excel exports).

I guess this is efficient, but damn. I was seeing some problems with how and when the page headers and footers made page numbers available to me, and I was hoping to avoid the whole issue of "when is a page header rendered" by incrementing a page number myself in a header.

It's worked before. It's not working now.

Still thinking about this... I think there's an answer. However, this fact might bite you in the rear for reasons that have nothing to do with page numbers; suppose you want to do something else that changes the table header each time it appears. It probably won't work as expected.

Fulano

8/27/2009 4:08:04 AM |

Lisa, simply the fact that you're even trying to help with this demonstrates that caliber of professional you truly are! I congratulate you for you skills, and for keeping your word. Even if you were never to find a solution, I am EXTREEMLY grateful for your efforts.

That's nice of you to say. Unfortunately, in this case, I think it's less about being a professional and more about not wanting to be beaten by a stupid problem <g>. Which I'm sure everybody reading this can identify with...

The good news is that *maybe* I've got something that will work, under certain circumstances. There will be limitations. The bad news is I still haven't got it 100%, even with the limitations and I'm going to go visit Jonah and His Parents now. So, more later, I hope.

Fulano

8/27/2009 3:56:06 PM |

Hi Lisa, I would be extremely satisfied if it simply worked with PDFs. I just need to publish the report in PDF and I need to pass the page numbers to the report's body. If it can do that, I'm perfectly content!!!

Unfortunately, this doesn't look like an issue of "different rendering formations"...

So far I would have to set conditions like this:

* -- the "table of contents" section or the header section in which you are putting these page number (with or without navigational jumps) would have to be either one page or a known number of pages. Or you'd have to set a conditional page break every <x> number of items in the header section, so that you could use the total number of items divided by the number of items per page break and be able to know how long the header section was...

* -- each subreport would have to be no more than a page long and each would have to start on a new page.

I'm not sure this is worth it... because I don't know if it would meet your specs.

Tell me some more about the design of your report (email is fine). Maybe I can come up with another idea.