About sub-report type forms

Sub-reports are reports that are designed to promote the reduction and reuse of reports by repeatedly reusing a sub-report within one or more parent reports. During the execution of a parent report, all referenced sub-reports are also executed and their outputs are merged into the output of the parent report. This allows for commonly used report content, such as notes, to be easily added to one or more parent reports.

Any Report type form can be used as a sub-report. There are no special requirements that make a Report type form eligible for use as a sub-report. Sub-reports are added to parent reports by setting the Sub-report Form and Sub-report Parameters properties of any report type region within the MainFlexLayout component of the parent report.

When a report type region of a parent report is specified to contain a sub-report, the entire region becomes a placeholder for the sub-report and cannot contain any additional components. During design time, the sub-report region displays the sub-report name and is shaded as disabled, to visually set it apart from other regions. During runtime, the sub-report region is replaced by any regions that are rendered by the sub-report.

Even though any Report type form can technically be used as a sub-report, the typical sub-report will contain a limited number of regions that are of the similar region type as the region they will replace within the parent report. All regions rendered by a sub-report are copied in sequence into the parent report where they will replace the report type region in the parent report. That means that sub-reports that replace Detail regions should also contain Detail regions, even though that is not specifically required.

Page breaks and page renumbering properties in sub-report regions are honored in the parent report. If a sub-report region contains a page break, then that page break will be inserted into the parent report at the same point where the sub-report region is inserted into the parent report. Many combinations of before and after page breaks can be used on both parent report regions and on sub-report regions to produce many varying layouts. Page renumbering for the overall report can also be influenced by the page renumbering properties of the sub-report regions.

VisibleWhen properties on regions in both parent and sub-reports can be used to influence the visibility of the regions rendered in the final report output. The VisibleWhen property on report type regions of the parent report can influence the overall visibility of the entire sub-report. The VisibleWhen properties on each region within the sub-report can influence the visibility of each individual sub-report region or the cumulative sub-report. Variables and collections are not shared between parent reports and sub-reports. It is important to note that the VisibleWhen property in the parent report can only contain references to variables and collections that are in the parent report and the VisibleWhen properties in the sub-report can only contain references to variables and collections that are in the sub-report. Therefore, if you desire to hide an entire sub-report based on the (non-)existence of data in the sub-report, then you will need to use VisibleWhen properties on all regions in the sub-report to influence the visibility of the entire sub-report.

Sub-reports are called in a similar fashion as other Report type forms, using phrases from a Run Form event handler, such as SETVARVALUES. In the parent report, use the Sub-report Parameters property of the report type region to specify calling parameters for a sub-report.