Powerful, Reusable Subreports for Your Reports

Often reports consist of similar, repetitive sections like a number of charts or crosstabs just filtered for different categories but otherwise identical. Or tables and subtables that have a preselected set of columns you want to have wherever this table is used. List & Label 26 now helps you and your users to get rid of the tedious task to maintain such reports and apply changes to all instances of objects. You can add real subreports that contain exactly the required items and maintain those in one single place.

Introducing C++ Support for Multiple Report Containers

During our Roadshow this fall, the question I was asked the most was "why do you support certain features only for .NET". Most notably, multiple report containers (since LL20) and nested tables (since LL21) were only available for .NET databinding. The reason for this is the necessity to support a special and – until now – undocumented COM interface for passing the data to List & Label. We decided to leave this interface undocumented in version 20 in order to be free to apply changes without breaking customer code. We had to make sure the interface was ripe. Now we are and here we go.

Supporting Multiple Report Containers

Since we introduced the report container in List & Label 11, the one remaining feature request that kept coming in was “could we have multiple report containers, please”. Many cases can be covered by using a multi-columnar layout for the report container as a workaround or combining distances between container elements and changes in alignment to get the visual impression of separated tables. But these workarounds are not very discoverable and they are just that – workarounds.
In version 20 we’ll introduce a brand new databinding mode for the .NET component which will replace the old one seamlessly. You won’t need to apply any code changes to profit from this new mode. However, under the hood things will be working quite different then.