September 24, 2015 at 8:15 pm
I need to produce statements with a "long" header for page one of the statement (including name, address, and statement total) and then a "short" header for page two and following (name only). This needs to work in PDF or print rendering, not just in the browser environment.
The only way I have found to do this is to put part of the info (the name only) in the Page Header and the rest of the information (address, statement total) in a Group Header. Of course, because I can't put data directly in the Page Header region, I have to use a workaround with custom code to make it work. And it does work about 90% of the time. But sometimes the last page of one statement has the name of the NEXT statement recipient in the Page Header. I can't put my finger on exactly what triggers this bug (for lack of a better word), but it seems to be related to the attempt of the rendering agent to keep the final subsection all on one page.
I posted earlier about the bug per se, but what I really need is a workable solution to getting the format correct on these statements, and if there is a completely different way to do it, I'm eager to hear about it. I've been trying various approaches for over a year, and this "header bug" keeps undermining everything I've tried.
September 25, 2015 at 8:02 am
I finally found an acceptable workaround for the formatting I want. I moved the repeating header information out of the Page Header and into a separate grouping that is a child to the return address information group level and a parent to the grouping that contains the rest of the data. It is a compromise design, because the other arrangement is definitely preferred, but at least it can work.
What I have learned from this is that you should not rely on any method of putting dataset data into the Page Header or Page Footer. There is a bug that will, under some circumstances, put the wrong data up there. Maybe it is just the complexity of this statement's report design that is making is susceptible to the bug, but now that I know it exists, I am unwilling to risk running into it again in any report design.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply