Duplicate report rows

rbuser

Hi,
using RB 16.0 with Delphi XE7

We are having problems with duplicated rows in a report that uses a
JITPipeline. The problem occurs when dynamically removing headers &
footers. The duplicate rows occur around the page breaks.

We use Gnostice to export reports to different formats. When we export
to Excel, we dynamically make a couple of changes to the report - any
header is only printed on the first page, and footers are removed
entirely (this is done so the data is uninterrupted). It's done
something like this:

if Assigned(TppReport(ppViewer.Report).FooterBand) then
TppReport(ppViewer.Report).FooterBand.Visible := False;
TppReport(ppViewer.Report).OnStartPage := OnStartPageEvent;

// Do export

procedure TAgRBPreviewForm.OnStartPageEvent(Sender: TObject);
begin
{ Only show the header band on the first page when exporting to xls }
if Assigned(TppReport(ppViewer.Report).HeaderBand) then
TppReport(ppViewer.Report).HeaderBand.Visible :=
TppReport(ppViewer.Report).PageNo = 1;
end;

// When finished, the footer is made visible again & the temporary
OnStartPage event disconnected


It turns out that if we apply this code to the report when printing (IE
no exporting), the same problem occurs.


When the report is printed without modifying headers/footers, everything
works normally (no duplicates) and the JITPipeline.RecordIndex behaves
like this:
...
28
29
30
29 <-- RecordIndex set back 1 here, but this appears normal - no
duplicate rows appear.
30
31
...

When the report has the header/footer removal code is applied,
JITPipeline.RecordIndex behaves like this:
...
28
29
30
29 <-- Normal "1 step back" here
25 <-- Bigger jump here, then increments sequentially again until near
the following page break. Duplicate rows result.
26
...

Are we do things incorrectly, or is this an RB issue? Your help in this
is greatly appreciated.

Regards,
Steve Spralja

nicocizik

Hi Steve,

One option is to use the Title band instead of trying to hide the header
as it only displays on the first page by definition.

In my testing with a very simple JIT Pipeline app and your code, I was
not able to recreate this behavior.

If possible, please create a minimal example I can run here that
demonstrates this issue and send it to support@digital-metaphors.com in
.zip format so we can track down the problem.

rbuser

Hi Nico,

Thanks for your response, and apologies for my late reply - I've been
away until today.

I was able to fix the problem by putting this code:

TppReport(ppViewer.Report).Engine.Reset;

in our custom preview form, just before the export to Excel.

While I was stepping through the RB source when I knew duplicate rows
would occur, I noticed that TppEngine.RestoreFromCache was being called,
but I couldn't see the actual saving-to-cache happen.
I then noticed that the actual record numbers being restored from the
cache corresponded with the records where the "1 step back" of the
record index (see previous post) occurred in the previous generation of
the report. The engine.Reset was a result of trying to clear the cache.

So, are we doing something wrong here such that we need this call? It
seems like it should not be required.

Unfortunately I've so far been unable to produce a minimal example of
this, without using Gnostice. I suspect I could use PrintToDevices, as
it seems that's what Gnostice are doing...

Regards,
Steve

nardmoseley

Hi Steve,

The issue is caused by dynamically removing the header/footer. That affects
pagination. You would need to that prior to previewing the report (i.e.
calling Report.Print).

The RB native export devices: XlsReport, XlsxReport, XlsData, XlsxData can
be configured via the Report.XlsSettings. The properties
XlsSettings.SingleHeaderOnly and SingleFooterOnly can be set to true, to
specify they appear only a single time. For details on these devices see
the RB Help topics for TppXlsSettings, TppXlsxDataDevice,
TppXlsxReporDevice, etc



Best regards,

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

rbuser

Hi Nard,

thanks for your reply.

For most of our reports, when the user clicks the Print button, our
custom preview form is presented. It is from this preview form that a
user can export the report to another format. Changing how this works
would be painful - the export really needs to happen from the preview
form. Is there anything wrong with calling TppEngine.Reset in this
manner? The report appears to be correct when this is done.

Unfortunately using the native RB export devices is not an option for us
at this time.

Regards,
Steve Spralja

rbuser

Hi

I'm really hoping someone can answer this question:

Is there anything wrong with previewing a report, then changing the
header/footer visibility, then calling TppEngine.Reset, and then
printing/exporting the report? This appears to work, but are there any
gotcha's etc?

We are getting close to our next major release, so this issue is
becoming more urgent for us.

Regards,
Steve Spralja

nardmoseley

Hi Steve,

ReportBuilder is not designed to have a single TppReport instance that is
producing two different sets of Page objects, one to Preview and one to
export. The Preview is live and interactive - the user can scroll to first
page, last page, etc. With the scrollable page Preview it is able to cache
pages, so it may work for simple cases or it may appear to work, but I would
expect issues.



Best regards,

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

rbuser

Hi Nard,

thanks for your response.

I assume the same holds true for the native RB export settings you
mentioned (XlsSettings.SingleHeaderOnly / SingleFooterOnly) - one would
first have to set these settings, then preview the report, and then
export it?

Regards,
Steve Spralja

nardmoseley

Report.XlsSettings should be set prior to calling Report.Print, but they
have no affect on Page generation, preview, etc.

The report layout (Report.Bands[ ].Objects[ ]) represents a model used to
generate report Pages. Pages are sent to Devices. Devices translate Page
objects to output formats.

Report ---> Pages ---> Devices ---> native output (screen preview, printer,
Xlsx,...)

The XlsSettings properties are applied to the Xls/Xlsx export devices. The
export devices use these property values to determine the export behavior.
This has no affect on the report model, the preview, etc.



Best regards,

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