An UpdatePanel completely replaces the contents of the update panel on an update. This means that those events you subscribed to are no longer subscribed because there are new elements in that update panel.
What I've done to work around this is re-subscribe to the events I need after every update. I use $(document).ready()
for the initial load, then use Microsoft's PageRequestManager
(available if you have an update panel on your page) to re-subscribe every update.
$(document).ready(function() {
// bind your jQuery events here initially
});
var prm = Sys.WebForms.PageRequestManager.getInstance();
prm.add_endRequest(function() {
// re-bind your jQuery events here
});
The PageRequestManager
is a javascript object which is automatically available if an update panel is on the page. You shouldn't need to do anything other than the code above in order to use it as long as the UpdatePanel is on the page.
If you need more detailed control, this event passes arguments similar to how .NET events are passed arguments (sender, eventArgs)
so you can see what raised the event and only re-bind if needed.
Here is the latest version of the documentation from Microsoft: msdn.microsoft.com/.../bb383810.aspx
A better option you may have, depending on your needs, is to use jQuery's .on()
. These method are more efficient than re-subscribing to DOM elements on every update. Read all of the documentation before you use this approach however, since it may or may not meet your needs. There are a lot of jQuery plugins that would be unreasonable to refactor to use .delegate()
or .on()
, so in those cases, you're better off re-subscribing.
Best Answer
I suspect you are running the original release (RTM) of .NET 2.0.
Until early 2007 validator controls were not compatible with UpdatePanels. This was resolved with the SP1 of the .NET Framework.
The source of the problem is that UpdatePanel can detect markup changes in your page, but it has no way to track scripts correctly. Validators rely heavily on scripts. During a partial postback, the scripts are either blown away, not updated, or not run when they are meant to.
In early betas, MS had the UpdatePanel try to guess what scripts needed to be re-rendered or run. It didn't work very well, and they had to take it out.
To get around the immediate problem, Microsoft released a patched version of the validator classes in a new DLL called Validators.DLL, and gave instructions on how to tell ASP.NET to use those classes instead of the real ones. If you Google for that DLL name, you should find more information. See also This blog post.
This was a stop-gag measure and you should
not use itavoid it if possible.The real solution to the problem came shortly after, in .NET 2.0 SP1. Microsoft introduced a new mechanism to register scripts in SP1, and changed the real validator classes to use that mechanism instead of the older one.
Let me give you some details on the changes:
Traditionally, you were supposed to register scripts via Page methods such as Page.RegisterStartupScript() and Page.RegisterClientScriptBlock(). The problem is that these methods were not designed for extensibility and UpdatePanel had no way to monitor those calls.
In SP1 there is a new property object on the page called Page.ClientScripts. This object has methods to register scripts that are equivalent (and in some ways better) to the original ones. Also, UpdatePanel can monitor these calls, so that it rerenders or calls the methods when appropriate. The older RegisterStartupScript(), etc. methods have been deprecated. They still work, but not inside an UpdatePanel.
There is no reason (other than politics, I suppose) to not update your installations to .NET 2.0 SP1. Service Packs carry important fixes.
Good luck.