A Guide to .NET Report Parts and How to Use Them
| Quick Start Guide | |
|---|---|
| What You Will Need |
ActiveReports.NET License Web Designer app Visual Studios or a standalone designer for ActiveReports.NET |
| Controls Referenced | |
| Tutorial Concept | How Report Parts can be used to speed up your report development. This blog dives into how to make and use report parts for ActiveReports.NET and mentions how you can speed up your report development and lower the bar for report authors to make good reports faster. |
This blog shows how to create Report Parts in ActiveReports.NET and make them available in the Web Designer.
Report Parts help teams reuse common report components and give report authors a faster way to assemble reports.
New to ActiveReports.NET? Download ActiveReports.NET Today to follow along.
What are Report Parts?
Report Parts are reusable groups of report items. Authors can drag a part into another report as a single item, with its styles, data bindings, and configured properties already in place. Report Parts are stored as mini-reports in .rdlx files, so use clear names or separate folders to distinguish them from standard reports.
It is best to make sure you have a naming structure, or to keep report parts files separate from your main report files, so users do not try to open the wrong file.
When opening a report part file in the web designer, it will appear on the toolbar side of the designer, and each part can be dragged and dropped onto the designer.
Why are they useful?
Report Parts reduce repetitive report-authoring work, promote consistent styling and content, and let teams maintain a shared library of common elements.
For example, you can reuse preconfigured report-item styling or copyright information instead of adding it manually to every report.
Unlike templates, Report Parts can be added or removed at any point in the report lifecycle. You can use both features, depending on your reporting needs.
How can you make and use them?
Create Report Parts in the Standalone or VS Designer, save them in an RDLX report library, and load that library into the Web Designer.
To create a Report Part:
In the Standalone or VS Designer, select one or more report items, right-click the selection, and choose “Create Report Part.”
The Exported Report Parts dialog lists the selected items and lets you configure the part’s properties.
Select “OK” to save the configuration.
From there, you can access the report parts collection on the Report’s Properties or by right-clicking the report in the explorer.
Use this dialog later to update a part’s properties.
Next, add the Report Parts library to the Web Designer.
Save the library in a location served by your application, then configure the Web Designer to load it:
<html lang="en">
<head>
@*get these files from the installation location for the package: \node_modules\@mescius\activereportsnet-designer\dist*@
<link rel="stylesheet" href="web-designer.css" />
<script src="web-designer.js"></script>
</head>
<body>
<div id="web-designer-host">
</div>
<script>
GrapeCity.ActiveReports.Designer.create('#web-designer-host', {
rdlx: {
reportParts: {
enabled: true,
libraries: [{
name: 'Sales',
path: 'Libraries/Lib_Sales.rdlx'
},
{
name: 'Marketing',
path: 'Libraries/Lib_Marketing.rdlx'
}]
}
}
});
</script>
</body>
</html>This configuration loads the Sales and Marketing report-part libraries into the Web Designer.
A useful setup reference is WebDesigner Report Parts. The sample shows a Web Designer configured with a library of Report Parts and restricted editing options.
In this configuration, the designer allows only text boxes and Report Part items.
This restriction helps provide a more focused authoring experience.
The Web Designer API provides additional options for controlling the available report items and editing features; see the API documentation in the resources below.
Tips and Tricks
-
Provide Clear Descriptions and Display Names
-
Use clear, user-friendly display names and descriptions for each Report Part and its properties.
-
-
Pre-configure Report Parts with Custom Properties
-
Define meaningful custom properties, such as colors, fonts, and titles, so end users can customize Report Parts without deep technical knowledge.
-
Group related properties into categories to make the property grid easier to use.
-
Decide whether end users can resize a Report Part after adding it to a report.
-
-
Keep Data Sources, Datasets, and Parameters in Mind
-
When a Report Part is added to a target report, its data sources, datasets, and parameters are copied individually.
-
Later changes to these copied dependencies in the library do not automatically update the target report, so plan updates accordingly.
-
-
Use Report Libraries to Organize Report Parts
-
Group related Report Parts into separate libraries for different user groups or report themes.
-
This organization makes shared Report Parts easier to manage and maintain.
-
Important:
Report Part definitions remain linked to their libraries, while data sources, datasets, and parameters are copied into each target report. Treat updates to those copied dependencies separately.
Conclusion
Report Parts help teams standardize reusable report components while giving authors a guided, flexible way to build reports. Use report libraries to keep common elements consistent and easier to maintain.
What other resources are there on the topic?
Docs page: Report Parts
API Doc: WebDesigner API
Want to Try it Out? Download ActiveReports.NET Today!