Slow report load v6.0

rbuser

In the past, I have absorbed the start-up delay of the first report
by auto-creating one report form. This puts the delay into the
application "load" delay.

This technique no longer works with v6.0 so that there is a significant
delay when the first report is called up.

Is there some way to move this delay back to the application start-up
("Splash Screen") time?

Jon
--
Jon Lloyd Duerdoth
Welsh Dragon Computing
http://www.welshdragoncomputing.ca
Y ddraig goch ddryg gychwyn

rbuser

> In the past, I have absorbed the start-up delay of the first report


John:

I am not sure where you are seeing the delay, or what is causing it. I have
never seen this. Is it data-access, report creation...? Do you have a large
number of reports on a form?

Thanks
Ed Dressel
Team DM

rbuser

Hi Ed,
Although I usually follow the one report one form model...
I do have one particular form that does have 4 reports.

The delay only manifested itself as of V6.0 and only on the first
time a report is invoked. I can then call any other report
without the delay (including the report that originally
had the delay). I am passing the report to a
procedure that sets up some default values (margins etc.) then
returns. I then do the usually Print etc.

The delay occurs on the first reference to a report property
such as the one I've illustrated below.

Not sure what's different in v 6.0 to cause this. :-(

BTW I really should not point at "load" as such... the delay
is somewhere around the first access to the report property.

Jon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
procedure SetReportPrinter(pRptID : string;
ppRpt : TppReport)

...
...

with ppRpt do begin
ColumnWidth := ColumnWidth + FieldByName('AdjColWidth').asFloat;

rbuser

I've done some further analysis. The absolutely "bare bones"
application that will exhibit the delay (for me):

1. drop a report component on a form
2. execute the following code:
procedure TForm1.Button1Click(Sender: TObject);
begin
with ppReport1 do begin
// next statement takes about 5 to 6 secs to execute
// pII (350)
ColumnWidth := ColumnWidth + 0.1;
// normal delay for print while page is created
// occurs here
print;
end;
end;

I have several other locations in my application where a simple
statement changing a label caption (at run-time) consistently
takes 5-6 s (on the first run).

Jon

rbuser

OK... so here's my "work around". Drop a Report component
on the first screen of application and place the following in the
OnShow....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// The following work around is used to reduce initial
// delay when the first report of the day is executed.
// The delay happens on a variety of statements such
// as the ColumnWidth assignment but also occurs on
// setting some label captions.
// Executing the following as part of the opening screen
// eliminates any subsequent delays.
with ppReport1 do begin
// next statement takes about 5 to 6 secs to execute
ColumnWidth := ColumnWidth + 0.1;
end;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jon

nardmoseley

Somewhere in the application the printer driver must be loaded. On some
hardware/printer driver combinations this causes a noticeable delay.
Particulary for some network printers.

In RB 5.x, the printer driver loaded when the application loaded. Now it
is delayed until some operation is performed in which the driver is
needed. In RB, Win API calls are frequently made that require the
printer driver. This occurs even when not printing, because RB must calc
the size of text, etc.

In RB 6, there is a new 'screen' printer option. It does not require any
printer driver at all. So one work around would be to set the
PrinterName to 'screen' until you are ready to print and then set it to
'default'.

rbuser

Nard,
Thanks for the clarification.
I think I will just stick with the "work around" that
forces the issue right at application start-up unless
you can see a problem with that approach.

Jon