After creating a report and formatting it to your satisfaction, the report needs to be integrated into your application. Understanding the best way to integrate reports into your application is essential for designing the best reporting solution. This makes chapter 3 one of the most important in the book.
There are a lot of different ways to integrate a report into an application, and some of the ways can be combined. The different combinations create an interesting matrix of possibilities for you to choose from. If this is your first experience at writing reports with .NET, it may seem a little overwhelming. To try to make this as easy as possible to understand, I first give you an overview of each option. This lets you see the big picture. Afterwards, I break down each option and show the steps to integrate it into your application. This is done for Windows applications as well as ASP.NET applications. Although the differences between Windows and ASP.NET can sometimes be minor, they are important and need to be addressed separately.
Sound good? Now let’s get started!
The first reporting related decision is whether the report is previewed before it gets printed. Many users like to see the report prior to printing it so they can verify that it will print the information they are looking for. This is especially true for reports that let the user choose how to filter and display the data. For other reports, you may not want to give the user the option to preview the report. An example is a reporting application that runs a batch print job at a scheduled time during the night. Requiring user intervention would cause the program to hang indefinitely until someone arrives to push the right button. Another example is a group of standardized reports that get printed every month. It is quicker for the user to select the reports to be printed by clicking on checkboxes and printing them all at once. Since the format and filters never change, making the user preview each report is unnecessary.
Previewing reports can be done in a Windows application as well as an ASP.NET application by adding a CrystalReportViewer control to the form/web page. Using the viewer control gives you many benefits. The first is obviously that the user can see what is going to be printed prior to printing it. If it isn’t exactly what they want, they can close the preview window and modify the report parameters until the report delivers the necessary information. No waste and another tree gets to live. Another benefit is that the viewer control has numerous built-in reporting functions that save you a lot of work. Rather than writing the code to export reports in different formats, the viewer has a button on the toolbar that does it for you. In fact, the viewer is so useful that I would guess that most of the applications you write are going to use it.
Of course, the viewer isn’t ideal for every situation. It requires user intervention for it to be useful. Another downfall of the viewer is that it can only view one report at a time. You can’t pass multiple reports to it. Displaying multiple reports simultaneously requires using multiple viewers.
If you decide to send reports directly to the printer, you are going to have to write the programming code to implement the functionality that you need. This could include writing code for printing the report, selecting the page range, and exporting the report to other formats. That’s a lot of work! Of course, this book makes it easy by showing you all the programming code to do this, but it’s still your responsibility to implement it in the application and test it. See the end of Chapter 14 for more information.
