Delphi Resource error and RTM file structure

rbuser

Hello All:

My app is Delphi 5/RB6.01 Enterprise. We have a form that holds all
available reports in a DBGrid. The user simply double clicks the grid and
the form prints.

If a user prints between 7 and 10 reports, upon freeing the form ( which
holds the reports ), the app chokes and produces a GPF.

The form is actually freed upon termination, so the GPF occurs on
exiting the app. If less than 7 reports are printed, typically no GPF is
produced.

The app works by loading a .rtm file into an existing ppReport
component, then calling the ppReport.print method.

The ppReport in question exists on the form as an object at desing and
at run-time. MY GUESS IS that loading multiple .rtm reports ( typically with
70+ DBEdit controls ) is producing some type of resource issue. WE DO NOT
FREE THE COMPONENT OR ATTEMPT ANY OTHER TYPE OF RESOURCE CONTROL. All we do
is load one .rtm file after another as the user prints forms.

WORKAROUND: We changed our code and appear to have fixed the problem. We
deleted the ppReport1 object from the prom and replaced it with a variable
of type ppReport. Each report creates the ppReport variable, loads and
prints the .rtm file, and then Frees the ppReport variable. NO GPFS are
produced under this workaround. Also, do we need to free the detail band in
this code ???

Is this behavior how ReportBuilder is desinged ??? Or, is it an
unintended issue with version 6.01 ??? The code is listed below:


Neil Huhta
Profit Monster Data Systems LLC



GOOD CODE:


Try
ppReport1:=TppReport.Create(Self); // FIXED CODE
ppReport1.DataPipeLine:= PipeDeal;

ppReport1.PrinterSetup.PaperHeight:=Datamodule1.TBReportsPaperHeight.Value;
ppReport1.PrinterSetup.PaperWidth:=8.5;
ppReport1.Template.SaveTo:=stFile;

TheDetailBand:=TppDetailBand.Create(Self); // FIXED CODE
TheDetailBand.Report:=ppReport1;
TheDetailBand.Height:=0.25;
ppReport1.SaveAsTemplate:=True;
ppReport1.Template.FileName:=
ReportPath+'\'Datamodule1.TBReportsReportFile.Value;
ppReport1.Template.LoadFromFile;
ppReport1.Reset;
ppReport1.Print;
Finally
ppReport.Free; // FIXED CODE
End;

digitalmetaphors

Basically, you are using the dbGrid much like our end user solution which
uses the report explorer. As a test, can you isolate the report printing
code out of your app by creating a test project based on one of our end user
report explorer demos. I don't know how much Delphi code you have for your
reports and if this is easily possible. It would be interesting to see if
an RB application by itself is causing the GPF.

You may want to run a memory resource watcher, like in TurboPower's QASuite.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Jim:

I am severly time constrained and cant take the time to build a test app
for a while. Our company is growing very fast and we are struggling to keep
up with demand.

There appears to be some kind of resource leak associated with the way I
am loading .rtm reports into the TppReport component. It is as simple as
this:

1) Can an existing TppReport object be used over and over to load in
.rtm reports ???

2) Or, to properly utilize a .rtm report, do we need to instantiate a
TppReport, load and run the .rtm report, and then free the TppReport and
repeat this process for every report printed ???


Under option 2, no GPF's are produced in my app.

Under option 1, GPF's are ALWAYS PRODUCED if more that 7 large reports
are run.

Our reports are structured with only a detail band and about 70 or so
components.

We have created several custom components which are TDBEdit decendents.
Could these components be a problem ???

We simply override the GetTheText Method, the constructor, and the
destructor. The constructor and destructor simply call inherited.

Please provide some input - we would be glad to provide you with our
sourcecode if necessary. Thank you.


Neil Huhta
Profit Monster Data Systems LLC

digitalmetaphors

Yes, one TppReport object should be able to load all of your report
templates. Sounds like your report frees your custom dbEdit subclass
objects when it is freed. But they aren't getting freed when a new template
is loaded. Place a breakpoint in your custom descendent component's Destroy,
to see if their destructor is getting called when you load the next
template.

You could also test if your component is the problem by removig it from the
equation. Load a few standard reports from our demos, into your database
and load them over and over again.

In 6.01, there was a leak which was fixed in 6.02. The preview icons were
never getting freed. Upgrading to 6.02 should help with resource
availability.


Cheers,

Jim Bennett
Digital Metaphors