ActiveReports 8
Master Reports
Show AllShow All
Hide AllHide All

Master Reports are like dynamic templates you can design for use with content reports. This assists users in creating reports that share common elements such as a logo in the page header or a web site link in the page footer. You design the master report with controls, code, data sources, and layout properties that cannot be modified from content reports.

Master Reports differ from templates in that they are loaded each time the report is executed. Therefore, you can modify a master report and the changes to the master report automatically appear in any reports that reference it.

Advantages of a Master Report

Designing Master Reports

When designing a master report, you use controls, code, data sources, and layout properties in the same way like you do in a normal report. A master report is valid on its own, and can be run without a content report. To prevent end users from modifying a master report, you can set permissions on the file to Read Only for that user or group.

In a page report, you can create a master report in a Continuous Page Layout (CPL) where the master report is converted to the RDLX-master file format that you can apply like a template to content reports.

A ContentPlaceHolder control appears in the toolbox when you convert a CPL report to a Master Report. This control provides the region to use for creating or designing a content report after applying a master report template.

Note: In a section report (code-based report), you have a concept similar to Master Reports. However, here you create a base report class in a standard report that other reports inherit. See Inherit a Report Template for further information.

Creating Content Reports

The reports on which you apply the master report are content reports. A content report is not valid on its own, and cannot be run without its specified master report.

When the user creates a new report and sets a master report on it, the design view is effectively the opposite of the design view of the master report. Any report controls overlaid by ContentPlaceHolder controls are not visible in the content report at design time, but are visible at run time. These are the only areas where users can add report controls.

While designing the content report the user can

While designing the content report the user cannot

Run-Time Sequence of Events

This is what happens behind the scenes when you run a content report.

  1. ActiveReports loads the content report.
  2. The loader parses the master report tag on the content report and requests the master report from the resource resolver.
  3. The master report is loaded into the definition.
  4. As each ContentPlaceHolder in the content report is parsed, it finds the corresponding placeholder in the master report and loads the content from the content report into it.
  5. Data sources, datasets, and fields are merged. The master report has higher priority if there is a conflict.
  6. Themes are merged. The master report has higher priority if there is a conflict.
  7. Report properties from the content report are added to those of the master report. In the case of the following properties, the content report has a higher priority in case of conflict:
    • Report Description
    • Report Author
    • Report AutoRefresh
    • Report Custom
    • Report Language
    • Report DataTransform
    • Report DataSchema
    • Report ElementName
    • Report DataElementStyle
    • Dataset filters
    • Report Theme
    • Report Code
    • All content inside the ContentPlaceHolder controls

Modifying an Aggregated Report Definition

When you run a content report, the content report and its master combine to form an aggregated report definition. Using the ReportDefinition API, you can save this aggregate at run time as a third report definition which has no master or content report. Once this aggregate is saved as a normal report definition (*.rdlx file) you can edit it as any other report definition.

See Also

How To

Support Forum