If you are developing Web applications with Visual Studio .NET, chances are you are well acquainted with ASP .NET (and if you aren't, you soon will be!). ASP .NET is not really a language, per se, but rather a set of interrelated technologies and components that come together in one framework to deliver robust Web applications. As a developer, you probably already know that the most important part of creating an application is the planning and design of the application, before the coding actually starts. The integration of Crystal Reports into Web applications is no different; a little bit of planning goes a long way.
The first thing we will need to do, before we write a single line of code, is to determine what type of reports we want to deliver in our Web application and how they are going to be used. Are they listing or grouped reports? Are they used to check data entry in a form before submitting it? What will the reports look like? Will users want to print the reports from their browser or export to another format such as PDF, RTF, or Excel? All of these questions can help you gather the information you need to design your reports and get a handle on how they are going to be delivered.
Even if you don't have your own reports to work with, you can still work through this chapter; sample reports are available in C:\Program Files\Visual Studio .NET 2003\Crystal Reports\Samples\ or in the download files for this chapter.
Once you understand the type of functionality you would like to deliver to the user, you can sit down and start planning how Crystal Reports will be integrated into your Web application. Crystal Reports .NET uses a feature-rich report viewer, available out of the box, which can be inserted onto a Web Form and used to view reports. The viewer itself has features that are similar to the Windows Form Viewer and has an extensive object model, allowing you to set the source of the report, the appearance of the viewer itself, and what happens when different events fire, among other things.
When working with Web applications, most users seem to prefer that we pop up an additional window to display reports. This allows them to have the full browser area to view the report, and we can pass properties like the report source and viewer settings to this Web Form. This allows us to use one report viewing form throughout the Web application and just set the properties we need each time.
The options for working with reports are endless. Based on users' access rights in your application, you could set a specific record selection formula or allow users to set and retain parameters they use frequently, or even establish profiles of their favorite reports, so they can run it with all of their settings in place with one click.
Like integrating reporting into Windows applications, the report integration should be driven by the user's requirements, but how these features are delivered is up to you. As you go through the rest of the chapter, think about how the different customization features could be used in your development. If you are not at a point where you can integrate these features into your application, the various properties, methods, and events are grouped together by function to make it easier to come back and look them up.
Was this article helpful?