List & Label Reporting Blog

List & Label 20 is quickly hitting the final milestones. I've been blogging about the new features since spring. This time, however, I'd like to share some insights into what happens as we shift near RTM.

In the last version we introduced a number of interactive features like report parameters, expandable regions, and dynamic sortings. Until version 20, using these in a web application was not possible as they result in a partial rerendering of the report or – for drilldown reports – trigger a brand new report. As the existing viewers didn't have a communication channel to a server control, this rerendering was impossible. 
Enter the new HTML5 viewer. This viewer is designed to work in almost any web browser. It is optimized for mobile devices and supports interactivity. It requires ASP.NET on the server side but can use any operating system on the client.

The improvement of our support for .NET has been a major focus in our feature planning process since the initial .NET beta release in early 2001. As more and more IDE vendors adopt CLR support for their languages and join the .NET community, .NET has become ever more important. Thus, version 20 will feature a wide range of new .NET features that make List & Label even more versatile when using it with CLR languages.

This has been a customer request that kept coming back over and over again – “please add the possibility to export to more formats from the preview window”. The typical workflow obviously is to check the result in the preview first. If all is well then an export to the final format is triggered. In List & Label 20 we now have added the possibility to export to the formats that were requested most – Microsoft Excel, Microsoft Word and XHTML. These formats were added to the already existing PDF, Text and Image formats.

From the perspective of an Office User, this was one of the major missing features in List & Label so far. In Microsoft Excel, for example, you often find yourself styling cells to resemble a headline. The workflow here is to just style one cell and then use the format painter tool for the other cells. This saves a remarkable amount of time. In List & Label, you could have used a multi selection of fields, however if you forgot (or – behold – didn't know) this feature, you'd find yourself repeating the same formatting steps again and again. And if you wanted to transfer the format of a whole object – e.g. a chart with all the fonts, colors, background settings etc. – there was no workaround to a huge lot of work. Enter the format painter tool…

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.

The two tool windows you'll probably use the most in the report designer of our List & Label reporting tool are the "Objects" window and the "Report Structure" window. The "Objects" window enables you to quickly select an object in order to change its properties and contents. The "Report Structure" window is used to configure the specific contents of a report container object, i.e. tables and subtables, charts, crosstabs and Gantt charts.

Using report parameters has become very popular since we've introduced them in version 19. A typical use case that will become even more seminal with version 20 of our reporting tool is using parameters to filter data (see last feature focus). This is something we've usually put on the "don't" list as databases can filter data much faster than we can. In the past, all records had to be passed to the reporting engine which then decided if a record should be used or not. A vast overhead for a task databases are usually optimized for. In version 20, we'll be introducing a new feature that allows List & Label filter expressions to be translated to native database filters, therefore hugely increasing performance (in principle, depending on the data this is "infinitely" faster).