A similar concept has been around using templates for a while. However, those were not as flexible as required because all objects from a template are included in the report linking to them. Subreports build on the same foundation, however they allow you and your users to select single report container items (i.e. single report parts) to be included while preserving the required hierarchy in the “parent” project.
For example, let’s consider this order list that contains all the fields you’ll probably want to include in such a list:
Now we could have a report using a report parameter for the order year in order to filter for different orders:
And another report where the orders are listed 1:n for each customer:
Note how the formatting and content is exactly the same for all three instances. The reason is simple: the first one actually serves as subreport for the latter two. Adding a subreport is straightforward. Just add a new item in the report container. It doesn’t matter if it’s a top level item or sub item. From the list of available options, choose the brand new “Sub-Report” option:
That’s it! The container item gets linked to the “main” report and will be loaded from the subreport every time the report is designed or printed:
On a side note, you can now also choose to import container items from other projects (see the screenshots above). In that case, the resulting report is fully detached from the source and can be changed independently.
When adding a report with several report container items, you get to choose which one to use:
You can either inherit or override a number of properties for the sub report. In the parametrized report example above, you’d need to add a filter to make sure only the matching orders are displayed. This can easily be done in the properties window:
Note that you can also select the column widths to adjust it to the available space. This comes in handy when reusing the sub-report in differently wide report containers.
Now this will make the live of report designers way easier, saving **loads** of time and avoiding to forget to apply adaptions to all the places where the same layout is required. And CI changes are a piece of cake, too.
Need more examples of callbacks on Alaska xBase++,please.
Not sure how this relates to this blog post. Our Xbase++ samples are a community contribution by DS-Datasoft. Happy to forward your request.