Dealing with Caveats
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 ...