ASP.NET AJAX UpdatePanel Control

Dealing with Caveats

The UpdatePanel control is certainly a very useful addition to the ASP.NET developer's arsenal, but replacing postbacks with asynchronous callbacks has a few side effects that can look strange if you don't fully understand how it really works. In this section, we present some of these unexpected effects.

Writing controls for use in UpdatePanel

Most WebControls should work in an UpdatePanel without modifications. Those that register scripts, in particular instance initialization scripts, though, may fail to work correctly. This is due to the fact that we're running under severely different assumptions. With regular postbacks, every user interaction basically throws away the old page and rehydrates a new one from scratch: you get a new page, a new DOM, and the scripts start from a vanilla state and are run again. With partial updates, the page potentially lives forever. During an update, the new script will run from a state that has been affected by those that ran before it, during the GET request and during previous partial updates. For that reason, it becomes essential that client-side objects dispose of themselves and that the server can discover what scripts need to be sent to the client again.

For those reasons, controls that want to work inside of an UpdatePanel need to follow a few rules, the main one being to start using ScriptManager registration methods instead of the ones ASP.NET 2.0 exposes on Page.ClientScript.

Eilon Lipton explains in great details how ...