AspNet2Holes

Validity checking of postbacks in ASP.NET 2.0 is a useful feature, but it can fail, generating mysterious messages that may begin, "Exception reported in __Page view...Invalid postback or callback argument...." One may also see, "Invalid postback or callback argument...Description: An unhandled exception occurred...." The messages go on with paragraphs that are likely to confuse a software developer, let alone a hapless user.

Many problems result from Internet Explorer or other browsers responding to user actions before a page has been completely constructed. An early postback may lack necessary information from controls that have not yet been fully processed by a browser. That is likely to happen when a page contains a grid or other bulky data or when it uses third-party controls that construct themselves on a client through JavaScript. In its designs for ASP.NET 2.0 and Internet Explorer, Microsoft evidently failed to anticipate such synchronization errors, and its marketing and support cheerleaders do not candidly acknowledge them either.

Validity checking can be disabled for all pages in web.config:

    <~system.web~>
        <~pages buffer="true" validateRequest="true"
          enableEventValidation="false" /~>
    <~/system.web~>

Validity checking can be disabled for individual pages by adding markup attributes ValidateRequest="false" and EnableEventValidation="false" to Page directives. Although sometimes recommended by novices, these are usually poor approaches, since they will open major security holes in applications. Yet how else to prevent users from tripping across ugly error boxes? Microsoft does not advise, and neither do makers of third-party controls such as Telerik.

Many such problems can be solved by strategic testing and design. Pages that contain bulky data or self-constructing controls must be tested aggressively to see whether early user action can cause errors. If such errors can occur, then controls that would provoke them need to be kept hidden until a page's controls have all been processed by a browser. The trouble-provoking controls are often buttons, but any control that is configured to generate a postback or an AJAX callback may be the source of a problem.

To hide a control, in markup add the option "visibility: hidden" to its Style attribute. At the end of the markup for a page, add a JavaScript block such as:

    <~script type="text/javascript"~>
        var oControl = document.getElementById
         ('<~% = ofControl.ClientID %~>');
        if (oControl != null)
        {
            oControl.style.visibility = 'visible';
        }
    <~/script~>

In the example, ofControl matches the ID attribute of a control that can trigger a postback and is initially hidden. The JavaScript block makes these controls visible. By the time it does so a browser will have processed a page's controls, and they should be prepared to participate correctly in a postback.

[Note: because of display limitations, characters "< " and " >" here are shown with a tilde ~ after or before them.]