Problem with SubReports "Keep Together" and global calculations

rbuser

If "Keep Together" is set against a subreport and its acted upon insofar
as a data scenario means that the subreport ends up starting on the next
page, then the details generation in the subreport happens too many
times and global calculations that are made from there (e.g. as per
http://www.digital-metaphors.com:8080/RAP/Calculations/How_To...Access_Subreport_Values_in_the_Main_Report)
will end up too high.

I've managed to completely reproduce this using your NexusDB EndUser
demo and one of my database tables, so I can send you the project and
data if needed.

This is a BIG deal for us as all our customers public facing reports
(Quotes, Confirmations etc) use this technique.

P.S. I think this might be the underlying cause of my "Groups and
Prevent Orphans" post on August 1.

nardmoseley

Yes, setting Subreport.KeepTogether to True will break that example. When
KeepTogether is true, the subreport will generate and if it cannot fit on
the page, then the page is restored to a prior state. The subreport
Variable's state is restored, but the main report is not aware of this.

For the rbWiki example, the solution is implement the main report
calculation in the subreport Summary.AfterPrint event. Note that the
calculation is different - the main report Variable is incremented by the
subreport summary total (Variable2.Value).

procedure SummaryAfterPrint;
begin
gVariable1.Value := gVariable1.Value + Variable2.Value;


end;


-
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Thanks Nard, but as I understand it this make global calculations
vulnerable to the potential deletion of TppVariable components in the
Summary band. For example users who don't want to display a CrewTaxTotal
in their subreport will just delete it and then contact support
wondering why they main report's TaxTotal is now wrong. I guess a way
around this is to create lots of invisible TppVariable components in RAP
(along the lines of
http://www.digital-metaphors.com:8080/RAP/Fundamentals/How_To...Dynamic_Variables_in_RAP)
to do all the work? If so, this is a pretty major bit of report
re-design and our customers who have heavily modified their reports will
probably NOT be able to do it themselves or even if they can do it by
following a knowledge-base article, will not be happy if they have, say,
10 variations of a quote report, each with about 6 subreports in them
supplying calculations to the main report. So is there no other way to
get around this?

Also, as an aside, I notice in the above cited example that
TppVariable.create() gets passed no 'owner' - doesn't this create a
memory leak or does the report has its own internal mechanism for
cleaning this up?

rbuser

On 26/08/2014 10:55, Paul Toms wrote:

Of course, it can be set to invisible, but they can just delete it
anyway (and Sod's law means they will ) without understanding the
implications.

nardmoseley

1. The example uses TppVariable.Create(nil) and then assigns
TppVariable.Band. The Report will free its bands. The bands will free the
components. (Delphi implements this behavior as Owner and Parent, in RB the
Band is essentially the parent of the Variable).

2. One solution to the end-user deleting essential variable is to use Design
Layers. Design Layers can be used to separate a report/childreport layout
into layers and Design Layers have options to control what the end-user can
see or edit. You can create a layer to host the Variables and then either
configure the LayerOptions so the layer is invisible to end-users or
configure the ComponentOptions so end-users cannot delete components.




-
Nard Moseley
Digital Metaphors
www.digital-metaphors.com