Home Subreports
New Blog Posts: Merging Reports - Part 1 and Part 2

REPOST- PLEASE HELP: Dynamically Loading Subreports to minimize maintenance

edited February 2003 in Subreports
I posted this subject on 2/8. I thought that I had a solution that would
work. However, now that I have redesigned my reports to dynamically load
subreports, I am finding that none of the events are working.
I am trying to dynamically load subreports because I want to avoid having
mupliple duplicate reports. I want to have one report that I can use
indivdually or as part (i.e., as subreports) of one or more master reports.
How do I achieve this if not by using one report a number of ways (i.e., in
master reports and as a standalone report)?

To avoid duplication, please refer to my posting on 2/8 which describes what
I am trying to do and the facts of the project.

Now, what appears to be happening is that when I dynamically load existing
reports as subreports, all of the component names are changed. Therefore,
none of the dynamic changes, that occur in events, to the controls that
reside within the reports are achieved.

If I dynamically load subreports that are not part of a TppReport and I have
code in events that use the existing component names within the reports, I
cannot compile due to the named components not existing at design time. So,
this is a "chicken and the egg" problem. If the component names exist at
design time then the report loaded into the subreport component are renamed
at runtime and the code to change the presentation of those components never
gets done. Otherwise, if I load a report with component names that do not
exist at design time, then I cannot compile.

How do I dynamically load existing reports and have code act upon the
components within the report to dynamically set the presentation? It seems
like I have to create these reports in code at runtime. Is that the
solution?

Comments

  • edited February 2003

    Common issues:
    ----------------

    1. When you load a report as a subreport, the component names may be changed
    by Delphi, because all names must be unique within the context of a common
    Owner. The Owner of the components is the form/datamodule upone which the
    component resides.

    2. You will not be able to compile event-handler code that references named
    components that do not reside on the form/datamodule. This issue arises
    because the report/sbureport is stored externally in a database or .rtm
    file - as you have discovered.

    Options:
    ---------


    1. Rather than load a report as a subreport, there is a technique that can
    be used in which a subreport can reference a report that resides on a
    different form/datamodule. An example can be downloaded from

    http://www.digital-metaphors.com/tips/SubReference.zip

    2. Use RAP, the run-time Pascal environment included with RB Enterprise. The
    code will then be stored as part of the report definition. RAP code refers
    to report objects by their UserName property. This is a property that all RB
    components have. It does not have the limitations of the Delphi Name
    property.

    3. Modify the report event-handler code so that it does not use the
    component names directly.

    example:

    procedure myLabelOnPrint(Sender: TObject);
    begin

    {typecase the sender}
    if (Sender is TppLabel) then
    lLabel := TppLabel(Sender);

    {or use the form FindComponent method}
    lComponent := FindComponent('myLabel');
    if (lComponent is TppLabel) then
    lLabel := TppLabel(lComponent );

    end;







    --
    Nard Moseley
    Digital Metaphors
    http://www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited February 2003
    Thanks Nard! I appreciate your thorough response.

    That did the trick. I used the SetReportProperty to associate the report.
    Everything works like a charm. Saves me (and my client) a lot of maintenance
    effort.

    Regards,

    Wayne L. McKittrick



This discussion has been closed.