Take the 2-minute tour ×

When jQuery is applied to elements in an UpdatePanel, when the UpdatePanel refreshes, the jQuery is not applied to the newly injected HTML.

This issue is resolved by using


to register a function to be called when the AJAX request is complete:

I've written a function that registers the function with add_endRequest, and also calls it at the same time:

Async.RegisterAndRun = function(callback) {
    //register function to be run when an update panel request is complete
    //also run the function right now.

Now all we need to call is



    AddMoreFancyjQueryToMyHTML('with', 'args');

My question is, can you think of a way to improve this? Currently it does what I need it to, and I never need to explicitly call add_endRequest which is nice.

share|improve this question
add comment

2 Answers

The first improvement I would suggest is to not use add_endRequest but add_pageLoaded(). The add_pageLoaded callback actually gets called when the page DOM is loaded and is ready to be consumed by other libraries.

I have faced many a times this problem of Update panel's DOM element ending up as ghost elements in jQuery selectors. However if you do not cache the DOM element within jQuery selectors, i.e. you are not doing

var myGrid = $(".Grid")

then you should be fine as doing a $(".Grid") will always get you the correct DOM element after an update panel update is over.

If however your problem is related to the event handlers associated with DOM elements, then one concise way of achieving this will be to have an event handler defined as


this will ensure that you need to call this code only once (and not on each add_endRequest). jQuery's live mechanism can automatically take care of elements appearing and disappearing from the page.

The main problem with this approach will be when your elements aren't ready until the first postback by the Updatepanel. To get around this, define function called (exactly as) pageLoad within your JS scripts

function pageLoad(sender, e) {
//jQuery event binding goes here.

This function will automatically be called by MS Ajax library on each Asynch postback call. This is a built in feature within MS AJAX libraries. Of course it also means that you can only define one "pageLoad" event handler within your code globally.

I recently wrote a client side framework which does a lot of clever things with DOM that gets changed by MS Ajax and jQuery working in parallel. It takes into account the race condition, the availability of DOM elements, the initialization and dispose of various event handlers etc. I will be happy to share it if you like.

share|improve this answer
Thanks for the comment. I usually avoid pageLoad() due to only one instance being allowed, and the necessity to sometimes have it in the master page, content page and user control. Also, you may not have noticed, but my Async.RegisterAndRun() method does actually call the callback function passed to it. –  Jamie Carruthers Mar 18 '11 at 11:17
You are welcome. Your client side framework should cater to the page hierarchy. The limitation of only being one instance of pageLoad allowed should not prohibit its usage. As I said earlier, the client side framework should be able to accept control's related JS scripts and initialize within the context of your entire application while managing the scope, event handlers and lifecycle of the control's script objects –  Nikhil Mar 18 '11 at 12:03
add comment
            with(Sys.WebForms.PageRequestManager.getInstance()  ) {

            function onBeginRequest(sender, args) {
         //       $.blockUI({ message: "<h3>.منتظر باشید</h3>  IranFairCo.com",overlayCSS:     { backgroundColor: '#00f' }});

            function onEndRequest(sender, args) {
           //     $.unblockUI();
share|improve this answer
I don't see how this is an improvement. The benefit of my code is the .NET AJAX is in a library and abstracted. –  Jamie Carruthers Mar 18 '11 at 10:13
add comment

Your Answer


