WPF Report Engine, Part 1

Most developers hate the process of generating printed reports. Although, there are well known report engines like Active Reports, Crystal Reports and rdlc Reports, but each report engine has its own issues. The main issue is the fact that developers have to work with different environments to generate reports. In many situations, the developer has to implement two interfaces; one for viewing & editing data in the application, one for printing. As you may know, WPF provides the ability to print almost everything. It tempts many people to produce their own report engines. Most of these open source report engines have been based on FlowDocuments. FlowDocument provides basic functionality for pagination and dynamic content and it temps many people to customize it to use as a platform for generating reports. For example, http://wpfreports.codeplex.com/ , http://www.switchonthecode.com/tutorials/wpf-printing-part-2-pagination and http://janrep.blog.codeplant.net/WPF-Multipage-Reports--Part-I.aspx are the best examples that tried to set up printing features using FlowDocuments. Actually, I don’t like the idea of using FlowDocuments as a foundation of report engines. FlowDocuments do not support most of the UI controls and the reports would be restricted to use the classes of System.Windows.Documents namespace. Most of them don’t support binding. (Apparently, Run class will support binding in the Framework 4.0). Although one can insert UIElement controls like StackPanel and TextBlock into the FlowDocument using BlockUIContainer and InlineUIContainer, but FlowDocument does not support paginations on them. The main idea behind my approach is using the current UI controls to produce reports. Using this approach, the developers don’t have to work with different environment to produce reports. Most of the data intensive applications display data in the form of Lists

read more


No Comments

Post Reply