EDN Admin
Well-known member
The UpdatePanel is the workhorse of the ASP.NET Ajax library. It is responsible for defining regions of a web page that trigger partial page postbacks (as opposed to
full page postbacks). Such partial page postbacks transfer less information between the client and server and have their user interfaces updated seamlessly, thereby
leading to a more interactive user experience. (For more information on UpdatePanels, refer to http://www.4guysfromrolla.com/articles/102407-1.aspx Using the
UpdatePanel .) One side-effect of a partial page postback is that the HTML elements within the UpdatePanel are replaced with the markup returned on postback. This
behavior is not noticeable and is not an issue unless you have client-side event handlers wired up to the elements within the UpdatePanel. Such client-side event
handlers are lost after a partial page postback.
Consider a very simple UpdatePanel that contains just a TextBox and a Button. Furthermore, assume we have JavaScript on the page that creates an event handler for the
TextBoxs
and
events, which "highlights" the TextBox when the user focuses it and unhighlights it when losing focus. Initially, this
script works as expected - clicking on the TextBox will "highlight" it. However, things break down once the Button is clicked. When the Button is clicked the UpdatePanel
triggers a partial page postback and submits an asynchronous HTTP request back to the server. The requested ASP.NET page then goes through its life-cycle again, but this time
only the markup in the UpdatePanel (and the hidden form fields on the page) are returned to the browser. The UpdatePanel then overwrites its existing markup with the
markup just returned from the server. Unfortunately, this overwriting obliterates the
and
client-side event handlers, meaning that
selecting the TextBox no longer highlights it.
In short, if there are client-side event handlers attached to HTML elements within an UpdatePanel it is imperative that they be rebound after a partial page postback.
This article looks at three different ways to accomplish this. Read on to learn more!
http://www.4guysfromrolla.com/articles/090810-1.aspx" class="readmore Read More >
View the full article
full page postbacks). Such partial page postbacks transfer less information between the client and server and have their user interfaces updated seamlessly, thereby
leading to a more interactive user experience. (For more information on UpdatePanels, refer to http://www.4guysfromrolla.com/articles/102407-1.aspx Using the
UpdatePanel .) One side-effect of a partial page postback is that the HTML elements within the UpdatePanel are replaced with the markup returned on postback. This
behavior is not noticeable and is not an issue unless you have client-side event handlers wired up to the elements within the UpdatePanel. Such client-side event
handlers are lost after a partial page postback.
Consider a very simple UpdatePanel that contains just a TextBox and a Button. Furthermore, assume we have JavaScript on the page that creates an event handler for the
TextBoxs
Code:
focus
Code:
blur
script works as expected - clicking on the TextBox will "highlight" it. However, things break down once the Button is clicked. When the Button is clicked the UpdatePanel
triggers a partial page postback and submits an asynchronous HTTP request back to the server. The requested ASP.NET page then goes through its life-cycle again, but this time
only the markup in the UpdatePanel (and the hidden form fields on the page) are returned to the browser. The UpdatePanel then overwrites its existing markup with the
markup just returned from the server. Unfortunately, this overwriting obliterates the
Code:
focus
Code:
blur
selecting the TextBox no longer highlights it.
In short, if there are client-side event handlers attached to HTML elements within an UpdatePanel it is imperative that they be rebound after a partial page postback.
This article looks at three different ways to accomplish this. Read on to learn more!
http://www.4guysfromrolla.com/articles/090810-1.aspx" class="readmore Read More >
View the full article