Distributing Custom Printing for Clients

rbuser

I am using RB 6 Standard and Delphi 6.02. (RB7 real soon - D7 probably
never)

I have a large application that prints a number of standard forms and
reports. I also print some custom reports for a few of my clients that I
need to distribute seperately. Since I will be using .BPL packages I had
considered adding the custom forms to a package and dynamically loading it
if it was available. I have also thought about distibuting and .EXE file
with the custom form and just passing command line parameters to determine
that data requested to print.

I was wondering how others handle the distribution of custom printing on a
client by client basis. Any novel solutions I haven't considered?

-Johnnie

rbuser

I am experimenting with saving the reports to a template database. I have
no problem saving them using the instructions in the developer guide, but I
notice that using that option does not delete the report objects from the
form they are stored on. The form is still populated with a number of
TppdbText objects, and others.

Should I delete the individual report TppReport components and then just add
a new one to be loaded at run-time with .LoadFromDatabase?

How will this affect text fields that I fill at run-time? Will I need to
define them now using a JIT data component?

Also, will using the database for templates speed up the load time on a form
which right now holds have 20 TppReports?

Thanks; I think the database will be the best approach.

Johnnie

digitalmetaphors

You could take your 20 reports on a form and save them individually as
templates to the database. You could use one TppReport object on a form to
load each template individually at runtime. However, you have event
handlers for the report components which tie your reports to the form class
methods. You may want to look into using RAP (RB Enterprise) to store the
calculations inside of the template. The template is capable of storing both
the data access definition (DADE) and the calculations (RAP). This means
that the report is fully portable. You don't have to tie your report's
event handlers to a form class and the template can simply be loaded into a
report. You also have the option of creating the form and report object on
the fly in order to have an object in which to load the templates.

If you haven't read through them before, there are some good articles in the
Tech-Tips newsgroup that has more details in the Templates thread.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

I have created a database with the report templates in it and now have one
report component on the form that loads the required reports as needed.

I have eliminated all event coding by moving my calculated fields to a
seperate JIT pipeline. For example to load my customers name or address
from a .INI file or to perform lookups on other tables. This works fine (so
far).

What I am curious about now is the creation of individual components in the
Data module where I have my Report component. Will these components such as
ppDetailBand, ppChildReport, ppFooterBand, ppMemo, ppDBText and ppLabel be
reused for each form or are they a one-to-one relationship with each of the
report templates? As I edit my reports I see more components being added.

-Johnnie Norsworthy

rbuser

:: What I am curious about now is the creation of individual components
:: in the Data module where I have my Report component. Will these
:: components such as ppDetailBand, ppChildReport, ppFooterBand,
:: ppMemo, ppDBText and ppLabel be reused for each form or are they a
:: one-to-one relationship with each of the report templates? As I
:: edit my reports I see more components being added.

I was able to comment out all of the report components mentioned that are
declared in my data module and the reports still appear to work fine. Is
there something that will cause them to recreate when editing new reports or
are they just gone forever?

-Johnnie

digitalmetaphors

The report objects are owned by the form or datamodule where the report is
owned. If ppLabel1 (the component name) exists in a report on a
form/datamodule, then when you load a template into another report object on
the form/datamodule, all naming conflicts are resolved by renaming the
component which you are trying to create. If the template you are loading
into a second report has a ppLabel1 component, then new ppLabel1 will be
renamed ppLabel2 (if ppLabel2 doesn't exist on the form/datamodule). If you
have one report object, then when you load the template each time, the old
objects are freed before the new template objects are created. I'd recommend
using one report object and use that to load all templates through it.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Thanks for all of your assistance.

From what I can tell, the database approach to storing database templates is
the best way to go for my application and I'm really glad I checked into it.

-Johnnie