The Invisible ReportViewer
An interesting bug report came in recently regarding toggling the Visible property on the ASP.Net ReportViewer. It’s fairly subtle and I don’t believe many people are running into it. But the solution isn’t obvious, so I want to make the information available in case you run into it.
The bug report placed a ReportViewer control on a page and initialized it in a standard way, such as declaratively in the ASPX file or in the Init event at the page level. The only thing that was unique to this particular page was that the viewer was initially hidden (ReportViewer.Visible = false). The viewer was made visible in response to a user action on the page, such as a button click. The problem happens during the button click event: while the control itself became visible, the report content did not.
The underlying bug comes from the way the ReportViewer tracks changes internally. In this case, the report definition is specified during the initial GET request and persisted by the report viewer. On a later postback, the viewer is made visible. The bug in the viewer is that while it does track the fact that the report definition has changed, it doesn’t keep that information across postbacks. Since the viewer becomes visible during a different postback than the one in which the report definition is specified, the ReportViewer doesn’t recognize that it needs to initiate processing of the report when it becomes visible.
Fortunately, there are two easy ways to work around this problem:
- Postpone setting the report definition until you make the ReportViewer visible.
- When making the ReportViewer visible, also make a trivial change to the ReportViewer to trigger a definition change. The easiest way to do this is to toggle the value of ReportViewer.ProcessingMode (e.g. set it from Remote to Local then back again).