How To Speed Up Display of Form?

rbuser

Hi,

I am using RB 6x and my problem is that my forms are loading very
slowly whenever a TppReport component is placed on them. As more and
more TppReport components are placed, the forms load more and more
slowly. This is very frustrating.

Is there a way of speeding up the loading of forms with many TppReport
components on them or do I have to place only one TppReport component
per form?

Does anyone have a better way of doing this?

Thanks.


Regards,
Frederick

rbuser

Frederick:

Each ppReport item had label and data objects associated with it. The
more of these you place on a form, the more stuff that needs to be loaded
upon creation of the form. Are you also placing multiple ttables on these
forms ??? Are all of these ttables being opened when the form is shown ???

To offer exact advise, please provide some more input. However, given
what you have mentioned, I would offer several options as follows:

A) Generic form option - Create a generic form to be used to load all
reports. Place whatever pipeline you need either in a datamodule or in that
generic form. Convert all of your reports to .rtm files ( You need
enterprise edition for this option ). You can do this by converting all of
your calculations RAP calculations and removing all variable events in your
form. Click save as to save the report + calculations to an .rtm file. When
your user selects the report, you do the opposite, change a few of the
ppReport properties ( see on line help for .rtm files ), and load the
path+filename into the appropriate ppReport property. From this point
reportBuilder operates the same. You should find this option to be
reasonably quick. Also, you can have one exe for every client. Just ship
them the unique .rtm files they need.

Using option A, we also use streaming to create custom input screens for
these reports. We store them in .scr files ( .scr is our designation and is
irrelevent - they are essentially a .dfm file outside the exe ). The .scr
file is streamed to create a generic input window in front of the report. We
use ann-memory table in this generic input window to feed non-database
information to the ppReport object. This allows us to eliminate coding the
connections and to use the reportBuilder data aware components.

Place each form on its own .pas file. Create a generic form to load
these reports. Use class functions to create a specific instance of the
class of selected report and show it. This will also conserve resources. The
demo has an example of this - I can also post some code, but my Delphi
computer is at work tonight. Let me know and I'll post it tomorrow. This
option requires you to place each unique report in the project, but you
never actually create the report. You use classes to clone it. The byproduct
of this approach is that you exe file gets larger.

I'm sure some of the ReportBuilder folks will also have some good ideas.



Neil Huhta
Profit Monster Data Systems LLC

rbuser

Hi Frederick,

there is an article called 'Minimize Size of Application .EXE' in the
tech-tips section under 'General'.
(I personally use 1 form per report and load the templates from file or
database during run-time)

regards,
Chris Ueberall;

Frederick Chin schrieb in im Newsbeitrag:
93m3ntgvukj59nbipb5gttsokraehconed@4ax.com...

rbuser

Frederick:

Each ppReport item had label and data objects associated with it. The
more of these you place on a form, the more stuff that needs to be loaded
upon creation of the form. Are you also placing multiple ttables on these
forms ??? Are all of these ttables being opened when the form is shown ???

To offer exact advise, please provide some more input. However, given
what you have mentioned, I would offer several options as follows:

A) Generic form option - Create a generic form to be used to load all
reports. Place whatever pipeline you need either in a datamodule or in that
generic form. Convert all of your reports to .rtm files ( You need
enterprise edition for this option ). You can do this by converting all of
your calculations RAP calculations and removing all variable events in your
form. Click save as to save the report + calculations to an .rtm file. When
your user selects the report, you do the opposite, change a few of the
ppReport properties ( see on line help for .rtm files ), and load the
path+filename into the appropriate ppReport property. From this point
reportBuilder operates the same. You should find this option to be
reasonably quick. Also, you can have one exe for every client. Just ship
them the unique .rtm files they need.

Using option A, we also use streaming to create custom input screens for
these reports. We store them in .scr files ( .scr is our designation and is
irrelevent - they are essentially a .dfm file outside the exe ). The .scr
file is streamed to create a generic input window in front of the report. We
use ann-memory table in this generic input window to feed non-database
information to the ppReport object. This allows us to eliminate coding the
connections and to use the reportBuilder data aware components.

Place each form on its own .pas file. Create a generic form to load
these reports. Use class functions to create a specific instance of the
class of selected report and show it. This will also conserve resources. The
demo has an example of this - I can also post some code, but my Delphi
computer is at work tonight. Let me know and I'll post it tomorrow. This
option requires you to place each unique report in the project, but you
never actually create the report. You use classes to clone it. The byproduct
of this approach is that you exe file gets larger.

I'm sure some of the ReportBuilder folks will also have some good ideas.



Neil Huhta
Profit Monster Data Systems LLC