Hide the Group header if the Sum(Field1) is zero

rbuser

Hi,

When I create a group and put a TppDBCalc in the groupheader, and set the
TppDBCalc.LookAhead = true, so I try to hide the Group header when the
TppDBCalc = 0
I write the code in RAP like this:

procedure GroupHeaderBand1BeforePrint;
begin
GroupHeaderBan1.Visible := ppDBCalc1.Value <> 0;
end;

But I find the ppDBCalc1.Value is the first record's value of the group, not
the sum value. So how can I know the sum value of the group before I print
the group header?

Thanks

Tao

digitalmetaphors

The look ahead variable doesn't have the value, until after the group has
generated. The report engine takes the value which is known at the end of
the group, and then reassigns the total new value to the draw command on the
page for the look ahead variable in the group header.

You will need to set the Report.PassSetting to psTwopass, and store the look
ahead group values in a TList in the first pass. Then in the second pass,
use these values for your calculations. There are two boolean properties of
the report called Report.Firstpass and Report.SecondPass which you can read
to determine the current pass in your event handlers.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Jim,

I hadn't seen this post until now and had resorted to having a second detail
TTable which I used to calculate/predict the DBCalc value before the
HeaderBand was generated. However, this meant that the detail records were
being processed twice - first by my copy table and then by the report
engine - which impacted on performance. This works okay when the DBCalc is
working on a detail table isn't easy to do when the report is based on a
single table.

When I tried your solution, i.e. storing the DBCalc values on the first pass
and using the stored values to set/clear the visibility of the HeaderBand on
the second pass, I got some unusual results.:

On the first pass the report displays with all the HeaderBands displayed.
On the second pass the unwanted HeaderBands are cleared on the first page of
the report and detail information which was previously on the second page
is "pulled" forward to the first page. Problems are:
(1) This "relocated" detail is then repeated on the second page. In fact,
the whole group is printed.
(2) Some HeaderBands on the second page are visible when they should be
invisible while others are invisible when they should be visible.
(3) Returning to the first page causes the problem (2) to be repeated on the
first page.

Problem (3) can be fixed by setting Report.CachePages although this has a
memory impact.
Problem (1) seems to improve when the HeaderBand is set to invisible
initially and then made visible as required. However, the detail information
which is "pushed" off the first page to make space for the HeaderBands is
not printed on the second page, although the HeaderBand is repeated on the
second page, indicating that the report engine "knows" that the detail has
overflowed.

There are two possibilities: (a) Your suggestion only works for a single
page report, OR (b) I should be doing something when the report ends each
page on the second pass.

Having used ReportBuilder (V4.23 with Delphi3) for just three months, I am
sure that the problem is with something I am doing, or not doing. To date, I
have re-written 51 of the 59 reports in my application, in parallel with a
major upgrade of the application, and I am wildly enthusiastic about
ReportBuilder's professional output and the productivity benefits it brings
to my programming activity. Keep up the good work.

Best regards,
Mike O'Grady.

digitalmetaphors

Most likely, I would guess that there is a problem in 4.23, which has been
fixed in subsequent releases. I looked at the archived 4.23 patches and
didn't see anything relating to calcs. Do you have a later version of
Delphi which you can test this approach with RB 6.03 demo installed? Sorry,
we dont support D3 in RB 6.03.


Cheers,

Jim Bennett
Digital Metaphors