Subreport foolishness

rbuser

Now let see if I have this right. If you set a subreport to child, which
you can print one after another on a page, you can't us header or footer,
because it isn't supported. I guess subreport mean a subset of a report??
AND if you change it to change it to section then you can't print the on a
single page, because each section report starts a new page. In what world
does this make sense? So how about 1) you fix the child report so the
header and footer work. or 2) Add a new property to section reports called
new page first or some such property like that to suppress the new page
before it starts printing.

rbuser

I'm sure you will get much better replies, but here ya go...


Correct, when set to child you must use title and summary rather than header
and footer. A child subreport basically is embedded with in the parent
report. The header and footer for the parent report print and the title and
summary bands print for the child.


Again yes. By setting a subreport to section it will start on a new page.
This allows you to take several individual reports and run them as one, each
starting on a new page rather than running together.

report so the
called

Actually, I believe this makes perfect sense. I use these features and they
work as advertised. If you need a report embedded within a parent report, a
child subreport is the way to go. If you need multiple reports to run one
after the other, section subreports do the job.

It sounds like you may be new to this product, or at least to using
subreports. Look at the demos and I believe you will come to appreciate the
way they have carefully been designed.


Eric Stewart
Republic Services of Southern Nevada
Las Vegas, NV

rbuser

I must agree with Jatchison. I have used sub reports in Crystal Reports and
they are simply embedded reports not some crippled versions of a report.
However, in ReportBuilder, as Jatchison pointed out, it's a completely
different story as sub reports appear to contain a sub set of the main
report class.

Personally I find this reduced functionality, especially in terms of headers
and footers, really frustrating. I can't believe that people quite happily
accept the fact that the workaround for this is the well known "grouping
trick". Personally I can't see why the reporting engine couldn't simply
perform this trick behind the scenes when a header or a footer is placed in
a sub report. Please help me understand.

One of the most frustrating things I found when I didn't know about this
limitation was that ReportBuilder quite happily allows me to add a header
and/or a footer to my sub report. However, I could not for the life of me
work out why it didn't want to show up. In the end I had to post a message
on one of the ReportBuilder newsgroups to simply be told that it's not
possible/supported.



-Andreas

rbuser

Hi Eric,

Well let's see. I've been doing RB for about 4 or 5 years, and strangely it
still irritates me when things that should work don't. So this must be DM
as Microsoft. It's not a bug, it's a design feature.

John

rbuser

Please add me to the list of voters to add the capability so that Subreports
*can* work in the manner described by Jatchison.

Please accept a my thanks and appreciation for all that RB does for us - and
that is a very great deal.

However, here we have spent many hours to acheive our desires with RB when
using SubReports in the manner described.

Title (beginning or report) and Summary (end of report) are clearly
different from Header (top of page) and Footer (bottom of page).

Issues we experience, and would like fixed:

1) omission to print Page Header/Footer of subreports
2) the insistance on starting a new page when we dont want it to.

Can you fix it?

Please...?

digitalmetaphors

Thanks for the suggestions everyone! We will put this on the to-do list.
This will involve rewriting the report engine to support this feature.


Cheers,

Jim Bennett
Digital Metaphors

digitalmetaphors

Section type subreports start on a new page, generate all pages necessary to
traverse the data and then fully complete the last page on which they
appear. They then allow any remaining components to generate starting on the
next page. Because they generate pages, section type subreports can control
the header and footer of each page. To add an optional "new page" boolean
property blurs this definition. RB will then contain "section" type
subreports which do not start on their own page but do complete the last
page they generate. Bizarre to say the least - which will lead to far more
support issues. Section means: Start on a new page, finish the last page
generated, headers and footers supported.

Child-type subreports start at the current position on the page, end at some
position on the page, then return control to the parent band. These often
participate in ShiftRelativeTo chains. Child type subreports are just that:
children. They do not support header or footer bands because the meaning of
such bands is ambiguous.

Assume we generate child type subreport A. It completes half way down the
first page. Child type subreport B is ShiftRelativeTo'ed subreport A. It
begins printing half way down the first page. If both Subreport A and
Subreport B contain 'Header' bands, then we have a problem. The defnition of
header band is: Print at the top of each page.

Given that definition should we generate the SubReport B header over the top
of the Subreport A header? Obviously not. Or perhaps header bands should
behave like "title" bands or "reprint on subsequent" group header bands when
printing in the context of child-type subreports. Possibly, but then we get
support questions regarding why the header in child type subreport B is not
printing at the top of the page (especially when Subreport A does *not*
contain a header.) Any way you slice this one you are talking support. So we
decided to *disable* (by setting Visible to False) header and footer bands
in child-type subreports. You can then emulate the "effect" of a header or
footer using the expected behavior of either title or reprint on subsequent
group header bands.

The one thing that probably should be added to the next maintenance release:
setting the visibility of header and footer bands back to Visible := True
when the PrintBehavior is switched back to Section. We should also consider
dimming or otheriwise indicating the status of the Visible property in the
Designer, so it is easy to see which bands have Visible set to False.

--
Cheers,

Tom Ollar
Digital Metaphors Corporation

rbuser

Hi Tom

Thanks for your information, and from your explanation I can see why RB
works as it does. However, whilst you may like to design the product to keep
support questions to a low, from my perspective the end-result of the
decision is a confusing situation (for we mere mortals!). I agree with your
choice to set visible in the next release, and to shade properties which
have no effect at runtime.

In the end, I find it very tricky to obtain *precisely* what I want, in
terms of pagination control, page headers / footers.

Typically my requirements are things like multi-page / multi-section
invoices; irrespective of what is printed, we may want a 'standard' header /
footer on each and every page, but then each section may require it's own
header/footer area (for column headings etc.))

1) to be able to include Section type subreports, and to have *some means*
to print a standard header/footer on each page. Maybe we also require the
subreport to have a header/footer but that should be printed below the main
report header, and above the main report footer.

Perhaps that in itself goes against the 'definition' of a header/footer, but
that is how I *understood* a header/footer to work, and that's actually what
I want.

2) For header / footer bands to print (in the same way) on Child type
subreports.

I appreciate that the modifications required may actually work against
certain basic design ideas of RB, but in the end, all I am trying to do is
'easily' make reports such as those above, which seem to me a fairly
reasonable requirement.

Also, please see a couple of comments below.

Thanks, in advance, for any enhancements you can perform which will assist
us all.

Regards

Clive

rbuser

I agree with you completely! I still cannot understand how subreports work,
and have a TERRIBLE time trying to add subtotals, etc. It still amazes me
how "poorly" this is done - and such a basic requirement. I am surprised
that more users have not raised this problem in the past.

What I really want is a report generator like MS Access - now that would be
something! So simple to use.

rbuser

But to be completely fair, whilst Acces may be simple, it is by *no means*
so powerful as RB, even without the RAP features.

We have discussed the SubReport difficulties here, and concluded that whilst
we think it frustrating, there is actually nothing we have been unable to
achieve one way or anther using RB; I am clear that some of those things
would *not* have been possible with the Access designer and engine.

My money still goes to Digital-Metaphors!