In ASP.NET Web applications it is common practice to place all startup code for the page in the Page_Load event handler, which is called by the Page.Load event.

In particular, control data binding code is usually stored within the Page_Load event handler. However, placing the binding code in this event handler causes a problem with ViewState. The problem and typical resolution is as follows:

• ViewState is used to persist two things across page reloads: the data that is bound to the control, and mouse clicks events performed on the control.
• ViewState is a string. Therefore both the data and click events must be serialized.
• During page reload, both the data and click events are restored from ViewState.
• The Page.Load event occurs after ViewState has been restored. If the Page_Load event handler contains control binding code, at time of page reload this binding code will overwrite ViewState, losing both the original data and the click events.
• This problem is typically experienced as controls that forget mouse click actions (e.g. a DropDownList selection) when the page reloads.
• To prevent data and mouse click events from being overwritten, any binding code in the Page_Load event handler is placed within a Not IsPostBack conditional block, which prevents the binding code from being called during postbacks.

This resolution makes one crucial assumption: that both the data and mouse click events can be serialized to ViewState. However, the CrystalReportViewer control binds to objects that are non-serializable (specifically, the ReportDocument class, the ReportClientDocument class or the InfoObject class.)

Since only the CrystalReportViewer control's mouse click events can be serialized to ViewState, binding to a non-serializable report class creates an irresolvable problem during page reloads:

• If the report binding code is placed within a Not IsPostBack conditional block, then the mouse click events from ViewState will be preserved. However, report binding does not occur. Therefore, an exception is thrown.
• If the report binding code is placed outside the conditional block, the report is bound correctly. However, ViewState is overwritten in the process. Therefore, the mouse click events are lost.

Recommended solution: move the CrystalReportViewer control's binding code to the Init event

The solution for the CrystalReportViewer control is to move your report binding code to the Init event, which occurs before ViewState is restored.

This solution raises one complication. Since the Init event is coded against less commonly than the Load event, it is harder to access. In Visual Studio .NET 2003 Web or Windows projects, the Init event handling code is located within the Web Form Designer Generated code region, an area that is typically hidden and reserved for generated code.

To resolve this, the following approach is recommended:

• Extract all CrystalReportViewer binding and configuration code into a private helper method named ConfigureReportViewing().
• Within the Web Form Designer Generated code region, place only a single line of code in the Page_Init() [Visual Basic] event handler or OnInit() [C#] event raising method: a call to the ConfigureReportViewing() helper method.

See Also

© 2021 SAP AG. All rights reserved.

http://www.sap.com/sapbusinessobjects/

Support services

http://service.sap.com/bosap-support/

Created with the Personal Edition of HelpNDoc: Easily create EBooks