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. |
In this blog, we will explore how to use Report Parts in ActiveReports.NET.
Report Parts are a feature that allows users to create preconfigured groups of report items, designed once and then dragged and dropped onto reports in the web designer. This enables your users to create reports more quickly and easily. This will help you and more of your users create complex reports without having to build them from scratch every time.
Want to Try it Out? Download ActiveReports.NET Today!
What are Report Parts?
Report parts are a grouping of report items that can be saved and reused on other reports. This allows users to drag the grouping out onto other reports and use it as a singular item. They will have their own style, data, and other properties already set, which allows you to cater to less technical report authors. The report parts themselves are stored as mini-reports in your system, holding the information inside an .rdlx file, like reports. There are some differences with the file that denote it as a report parts file vs a normal report, but as a note:
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 allow more experienced users to create small snippets of reports that a general user base can drag and drop into the report. This lowers the bar on the amount of knowledge needed to make reports. This will allow more people on your team to create reports and build a library of pre-made assets for them. This, in itself, will allow reports to be made more quickly, as you have libraries of common elements.
These common elements could be something as simple as preconfigured styling for report items or copyright info. Anything that had to be added to each report can now just be dragged and dropped on, rather than you or your team adding it manually to every single report.
It is also better than templates in some cases, as users can add or remove report parts and retrieve them cleanly, rather than needing to start over with a new version of the template. Using Report Parts allows end users to bring in template items at any point in the report lifecycle, avoiding the need to backtrack to retrieve the original template controls. So it is better in some cases, but you can always leverage both depending on your user base and reporting needs.
How can you make and use them?
Report parts are available in the web designer for the RDLX reports. Report Parts can be made in the standalone designer and VS Designer. Then they can be saved and then be usable as part of a report library for the Web Designer. Once in the library, they will be accessible to you or others with the designer for quicker report creation.
Let us review the process of making a report part.
It starts in the standalone or VS designer, and you can right-click one or more items in the report. This will bring up the context menu, which includes the option “Create Report Part”.
On clicking that, this menu will come up with the members you selected and some properties you can change.
You have to hit “Ok” after editing any properties you need for them to be saved to a workable state.
From there, you can access the report parts collection on the Report’s Properties or by right-clicking the report in the explorer.
This will bring up that dialog again, which also lets you edit the properties if you need to make any changes.
Next, now that these are created, we will need to integrate them into the web designer.
The process is pretty simple. Once they are created, it is best to save them to a folder and then host them in the area where you have your web designer. Below is the code you can use that will add 2 report parts to the web designer:
<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>Again, notice the report libraries are rdlx. Please make sure you clearly mark what constitutes a normal report and what constitutes a report part.
A good resource for setting up report parts is WebDesigner Report Parts. This is a webdesigner that has several report parts in a library. It showcases how you can make preselected parts of a report and lock them down for less technical users.
The designer will only allow textboxes and report part items.
You can change some settings around the report parts, but overall, you can see how to lock down the designer and integrate it.
Their API has additional options for these lockdown settings. If interested, please check them out in the resources.
Tips and Tricks
-
Provide Clear Descriptions and Display Names
-
For each report part and its properties, providing user-friendly display names and helpful descriptions will help guide end-users in customizing the parts
-
-
Pre-configure Report Parts with Custom Properties
-
Define meaningful custom properties (e.g., colors, fonts, titles) to allow end-users to easily customize report parts without requiring deep knowledge
-
Use property categories and descriptions for better usability as well
-
Define whether end-users can resize a report part after adding it to a report. Depending on your use case, it could go either way
-
-
Keep Data Sources, Datasets, and Parameters in Mind
-
While report libraries contain report parts, remember that the data sources, datasets, and parameters are copied individually when added to target reports
-
Modifications to these items in the library won't propagate immediately, so coordinate accordingly
-
-
Use Report Libraries to Organize Report Parts
-
Group related report parts in separate report libraries for different user groups or report themes
-
This allows for easier management and updates that propagate to all reports that use these parts
-
Things to note:
Any changes made to Report Parts used by other reports do not take effect immediately and will take some time to be reflected. In this way, they are not like sub-reports.
Conclusion
For development teams building reporting solutions, Report Parts provide a practical way to standardize report creation while reducing the manual work required of both developers and report authors. By creating reusable report components, organizing them into libraries, and integrating them into the ActiveReports .NET Web Designer, you can deliver a more guided reporting experience without sacrificing flexibility. Whether you're building self-service reporting for business users or creating a shared library of common report elements for your team, Report Parts help streamline development, improve consistency across reports, and make report maintenance more manageable as your application grows.
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!