tags:

views:

21

answers:

1

I am having serious performance issues with BlockUI and ASP.NET AJAX on my aspx page. I am trying simple element blocking but it is fading in with a a lag/delay. Does html errors on page would impact blockUI ? I might have some on my page. I am blocking a large div spanning well above the browser vertically. Also, the unblock works great for the same page (without any delay/lag). In case of a timeout on my Update Panel, the fadein works good too but just comes with a lag otherwise

function blockMaster()
{
    $(document).ready(function(){
        $('#ftMaster').block({message:"<h2>Just a moment...</h2>"});
        $('#<%=btnAJAX.ClientID%>').attr("disabled",true);
    });
}
A: 

I believe that HTML errors would prevent blockUI from working at all, were they serious. What happens when you comment out the block() call from $(document).ready() and call it manually via Firebug once the page has loaded completely? Is there still a delay? Do you have other handler functions that are being called on the ready event? Who calls blockMaster(), and when?

Simon
Thanks for the reply Nick. There isn't any delay when I block the div from firebug console. I just put document.ready there as I read somewhere it is good practise. I am just calling the block function on an Async Postback by a asp.net server control outside my updatepanel, I check for the postback control id and isinasyncpostback() and block the div if its matched.
Popo
Also when I test in IE, there isn't even a delayed fade, it just toggles to visible, fadeout works good.
Popo
The function you pass to $(document).ready() is called once during the initial loading of your page, when the DOM tree has been constructed (see http://api.jquery.com/ready/). It IS good practice to put JS initialization code there, however you usage doesn't make sense to me. You either call blockUI() on page load, OR as a postback. Try removing the $(document).ready() wrapping.
Simon