Limitations of RDL
I originally went with RDLC/ReportViewer for printing with WPF but found it very limiting. Some of the limitations I found were:
- RDL could only create the most boring of reports
- It was much more work to create a report using RDL than in straight WPF: The design tools are very primitive compared to Expression Blend and RDL deals only in tables
- I didn’t have the ability to use ControlTemplates, DataTemplates, Styles, etc
- My report fields and columns could not effectively resize and rearrange based on data size
- Graphics had to be imported as images – it could not be drawn or edited as vectors
- Positioning of items required code-behind rather than data binding
- Lack of transforms
- Very primitive data binding
Printing directly from WPF is very easy
Because of these limitations I looked into creating reports using pure WPF and discovered it was really quite trivial. WPF allows you to implement your own DocumentPaginator subclass that can generate pages.
I developed a simple DocumentPaginator subclass that takes any Visual, analyzes the visual tree, and hides selected elements to create each page.
DocumentPaginator details
Here is what my DocumentPaginator subclass does during initialization (called when first PageCount is fetched, or during the first GetPage() call):
- Scans the visual tree and makes a map of all scrolled panels inside ItemsControls
- Starting with the outermost, makes items in the ItemsControls invisible last to first until the Visual fits on a single page without any need to scroll. If the outermost can’t be reduced enough, reduces inner panels until it succeeds or has only one item at each level. Record the set of visible items as the first page.
- Hide the lowest-level items that have already been shown on the first page, then make subsequent items visible until they no longer fit on the page. Record all but the last-added item as the second page.
- Repeat the process for all pages, storing the results in a data structure.
My DocumentPaginator’s GetPage method is as follows:
- Look up the given page number in the data structure generated during initialization
- Hide and show items in the visual tree as indicated in the data structure
- Set PageNumber and NumberOfPages attached properties so report can display page numbering
- Flush the Dispatcher (
Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => {} ));) to get any background rendering tasks to complete - Create a Rectangle the size of the page whose VisualBrush is the visual being printed
- Measure, Arrange, and UpdateLayout the rectangle, then return it
This turned out to be quite simple code, and allowed me to turn practically anything I could create with WPF into pages and print it.
Additional reporting support
Now that my paginator is working, I no longer have to worry very much about whether I am creating my WPF content for screen or paper. In fact, often UI that I build for data entry and editing also works very well for printing.
From there I added a simple toolbar and some code behind, resulting in a full-fledged reporting system built around WPF that was far more capable than RDL. My reporting code can export to files, print to the printer, cut/paste page images, and cut/paste data for Excel. I can also switch any of my UI to “print view” with a click of a checkbox to see what it will look like if printed. All this in just a few hundred lines of C# and XAML!
At this point I think the only feature RDL has that my reporting code doesn’t have is the ability to generate a formatted Excel spreadsheet. I can see how this could be done but so far there has been no need – cutting and pasting the data alone has been enough.
From my experience my recommendation would be to write a paginator, then start using WPF itself to create your reports.