Using jQuery to display a modal UpdatePanel confirmation
AJAX, ASP.NET, jQuery, UI By Dave Ward. Updated October 15, 2008Note: This post is part of a long-running series of posts covering the union of jQuery and ASP.NET: jQuery for the ASP.NET Developer.
Topics in this series range all the way from using jQuery to enhance UpdatePanels to using jQuery up to completely manage rendering and interaction in the browser with ASP.NET only acting as a backend API. If the post you're viewing now is something that interests you, be sure to check out the rest of the posts in this series.
After the previous example of integrating jQuery and ASP.NET AJAX to display modal progress indication, there were requests that I follow it up with an example of also displaying the confirmation modally. So, I’m going to expand the original post with a technique for doing exactly that.
If you missed my first post on the topic, do be sure to read it first. Otherwise, this continuation may be difficult to follow.
Refactoring the progress indication CSS
In the previous example, our only goal was progress indication. So, it made sense to override BlockUI’s default CSS styling to display the progress animation. Now that we will be displaying two separate modal elements, that CSS will need to be refactored:
div.blockMsg { background-color: #FFF; border: 1px solid #ddd; height: 100px; text-align: center; width: 270px; } .progress { background-image: url(images/progress-indicator.gif); background-position: center center; background-repeat: no-repeat; }
This allows us to selectively apply the progress indication CSS, without it being tied to all BlockUI modal elements.
Applying that refactored progress indication
Now that the CSS is refactored, the original save Button event handler needs to be updated so that it applies this new progress class to its specific BlockUI element.
You’ve probably heard a lot of general praise for CSS selectors, but this task is a great, specific example of their usefulness. Since the BlockUI message doesn’t have an ID property, accomplishing this task without CSS selectors would be messy.
Conversely, jQuery makes easy work of this task:
// Add the BlockUI call as an onclick handler // of the Save button. $addHandler($get('Save'), 'click', function() { $('#EntryForm').block({ message: null }); // Add the progress indicator. $('.blockMsg').addClass('progress'); });
Immediately after the BlockUI invocation, we use jQuery to select the message container element that it created and add the progress CSS class to it. The end result is the same modal progress indicator that we created in the last example, without requiring that its styling be added to BlockUI’s defaults.
Swapping confirmation for progress indication
In order to display a modal confirmation dialog after the partial postback finishes, we’ll need to add some additional code in our EndRequest handler:
prm.add_endRequest(function(args, sender) { // Instantly remove the progress indication element. $('#EntryForm').unblock({ fadeOut: 0 }); // Block the form, using our Panel's content // as the block "message". $('#EntryForm').block({ message: $('#ConfirmSave') }); });
Specifying a fadeOut parameter for the unblock() call is important because BlockUI defaults to using a fadeOut value of 400 milliseconds. That normally looks great, but we want to instantly swap confirmation in for progress indication here, so it’s crucial that we remove the progress indication with no delay.
Immediately after hiding the progress indicator, we call block() on the entry form’s <div> again. However, this time we’ll use its message parameter to specify our contextually updated Panel as the element to be displayed modally.
The end result of these two operations is a seamless transition from a client-side progress indicator to the contextual confirmation dialog that we generated on the server-side.
A UI element to close the confirmation dialog
Now that we’ve displayed the confirmation dialog, the next natural step is to give the user a way to close it.
First, we need to add a UI element to the confirmation Panel:
<ContentTemplate> <asp:Panel runat="server" ID="ConfirmSave" Visible="false"> <h3><asp:Literal runat="server" ID="CustomerName" /> added</h3> <a href="#" id="CloseConfirm">Close</a> </asp:Panel> </ContentTemplate>
Wiring up functionality to that element
With the link added to our confirmation message, the final step is to wire up an onclick handler for that <a> element. We’ll wire that up in the EndRequest event:
$('#CloseConfirm').click(function(evt) { // Prevent navigation when the link is clicked. evt.preventDefault(); // Unblock the form, and remove the confirmation // div afterward. This prevents it from showing // up below the form after BlockUI releases it. $('#EntryForm').unblock({ onUnblock: function() { $('#ConfirmSave').remove(); } }); });
$addHandler would work work here too, so use what you’re comfortable with. I chose to use jQuery’s event handler mechanism so that the sample code contains an example of both methods.
The onUnblock callback function is necessary to remove the confirmation Panel from the DOM. Otherwise, it would simply revert to rendering below the entry form after unblock() completed.
End result: when the close link is clicked, the confirmation dialog will fade out over the course of 400ms and then disappear from the page completely.
Conclusion
I’ve been using this BlockUI technique in my applications for about a year. During this time, I have found it to be extremely powerful, yet easily implemented and maintained.
End users love the fade effect too. Often, the smallest details count the most.
If you’re wondering to yourself what good a modal window with a close button could possibly be, here’s a screenshot (from one of my apps) of the technique in action:

This BlockUI modal is presented to users after saving a somewhat complex form. We’ve found that blocking the page and presenting limited options improves productivity, by subtly guiding users toward desirable actions.
I hope this technique helps you find similar usability gains in your own applications.
Download the source and see it in action
Similar posts
What do you think?
I appreciate all of your comments, but please try to stay on topic. If you have a question unrelated to this post, I recommend posting on the ASP.NET forums or Stack Overflow instead.
If you're replying to another comment, use the threading feature by clicking "Reply to this comment" before submitting your own.
2 Mentions Elsewhere
- Dew Drop - October 13, 2008 | Alvin Ashcraft's Morning Dew
- October 22nd Links: ASP.NET, Visual Studio, WPF and Silverlight - ScottGu's Blog



Because you unblock and then block again, is there a window of time (however short) where the user’s UI isn’t blocked? Would it be better to add another modal with the confirmation and then unblock the original? Forgive me, I’ve not read the code at all yet.
Up until about 8PM last night, the example actually layered two .block() calls on top of each other.
It did work, but isn’t as clean because you have to manually specify an overlay opacity of 0 on the second .block() and then remove the .progress CSS class from the first one.
In my testing, I didn’t see any discontinuity between the modals, but I suppose it may be possible on a very slow machine. I’d be interested if anyone can reproduce that sort of problem consistently.
Hi….is it possible to have just the modal pop up without the confirmation message? My messages are displayed in the parent page ….
Thanks !
Sure. Check out the previous post in this series, for something like that: http://encosia.com/2008/10/04/using-jquery-to-enhance-aspnet-ajax-progress-indication/
it does not work when we use it within master page…
You’ll need to pay extra attention to your ClientIDs in a master page scenario. Take a look at this post and its comments, for some ideas: http://encosia.com/2007/08/08/robust-aspnet-control-referencing-in-javascript/
When using a master page your control name is named differently. For example if you have a button called “btnLastName” it will be called “ctl00_cMaster_btnLastName” this is how it is being rendered (Note: (1) cMaster is the name Content Place Holder on the Master Page(2)That is a lowercase L not a number one). So when using JQuery / JavaScript with master pages remember to use “ctl00_”Name of Content Place Holder on Master Page”_btnLastName. (Note: (3) To find the name of the controls when using a Master Page, run the page then right click on the page and select “view source”).
Great post. Thanks for sharing this
Is it possible to have the blockui work on a updatepanel. I want to have my code in a updatepanel that is displayed like a modal window. I am having trouble getting this to work.
Doing this so a user can page through results of images. Then select one and pass that value back to the page.
You should be able to accomplish that through the same unblock/block juggling shown above. This part:
Once again, another great article Dave! I do have 2 questions though:
1) I am using this technique on a contact form. This form has Validator controls on it. Without them, the blockUI plugin works beautifully, but once re-introduced and upon clicking SUBMIT, the client-side validation is bypassed and the loading icon just seems to not go away (i dont get my confirmation message at all!). I tried this on your sample code as well. Any thoughts?
2) I see you’ve made a note about it, but for instance – if I execute the submit routine the first time, I get my nice confirmation with the person’s name. Once I close it and immediately type another name and click SUBMIT, I get the confirmation message twice. My only work-around for this, is to make the “div.blockMsg” have a CSS overflow property set to hidden.
Thanks! And again, another great article
Try using UseSubmitBehavior=”False” on your button. BlockUI catches the form submission event and quashes it early, preventing the validators’ client side logic from running. UseSubmitBehavior False will inject a __doPostBack() onclick, instead of relying on the form submission.
Hey Dave,
Excellent Posts. I have some issues with this project. I am using your files to create a contact form. Once a user hits submit it executes some server side code and then diaply the modal popup. It all works fine for the first time. But if hit back and refresh the page and try to submit again it thows a script error and the modal popup never fires.
“parent node is null or not an object”.
Any suggestion on how I can fix this problem?
Thanks,
Tareq
Dave,
I have a LinkButton on my page. I wire up the OnCommand event for that link button to fire off some code in my codebehind. In the Page_Load method, I add an OnClientClick javascript call to that LinkButton that calls the .blockUI() method.
The issue seems is that as soon as .blockUI() is called, I’m experiencing the same issue that Shalan experienced. Since LinkButton’s don’t have the UseSubmitBehavior property, I found that even if I use the OnClick method for the LinkButton and not the OnCommand (which I believe submits the entire form?) I still get the post from the button blocked. Essentially as soon as I click the button, my post back dissapears. I can not debug to the codebehind in my Click event.
Is there something I’m missing here? Is there a default property that stops the .blockUI from catching all requests or posts, that I have to set?
Thanks in advance,
- Aaron
Dave,
I solved the issue by ensuring that my link button’s OnClientClick event had a
attached to it. I add this bit of code to the code that calls the .blockUI() method. After the .blockUI() method is fired off, it’s necessary to ensure that the post back occurs.
This manual call to __doPostBack seems to do the trick.
I got that clue from your post about what happens with the UseSubmitBehavior on regular buttons.
Thanks for all the info and examples. Really great stuff!
- Aaron
Dave, thanks a lot for wonderful posts.
I went a little crazier with blockui and put an updatepanel with detailsview in it. So it works like a master/details modal display. It works a great with displaying the data, however if you try to implement edit and update functionality, async postbacks do fire up but they don’t include any parameters from textboxes in the post. Therefore nothing gets updated. I’ve been looking around for the whole day I can’t find any info on that, do you have any ideas?
Thanks,
That’s probably due to how BlockUI moves things around in the DOM. You’ll probably find that it’s a severely uphill battle to make it work.
Matt Berseth has a good post on how to use a different jQuery plugin to do what you’re after: http://mattberseth.com/blog/2008/06/masterdetail_with_the_gridview_1.html.
Thanks again Dave, I’ll go ahead and use thickbox for that task.
Same problem with the linkButton and BlockUI, the postback isn’t working.
The call to the __doPostback function doesn’t work.
Solved inserting a timeout in the OnClientClick event:
setTimeout(‘BlockPage()’,10);return true;
LinkButton Code:
‘ >
Great work! I’ve been reading all your articles and learning a bunch… and realizing I have a bunch to learn of some new topics!
I have a similar problem I believe, and it seems you’ve done enough work in this area to point me in the right direction.
Basically, I want to display a lightbox after an asp.net-ajax call inside my updatepanel. In my first application, it will be from a navigation button on an asp:wizard control. As that control posts back, some business logic runs to validate some of the users’ selections. If things are fine, we just advance to the next step. If not, I want to use some lightbox to display a message.
I’ve detailed my efforts so far here:
http://stackoverflow.com/questions/504464/how-to-show-a-lightbox-dialog-from-an-asp-net-ajax-response
Thanks!
Dave,
is there any way to fire action on reply from server by using code behind file, not web service + jQuery?
Or here is only one way – jQuery+web service?
You could use a page method instead of web service, if you prefer the code located in the page’s code behind.
Dave,
I’m experimenting with your example and added a second button as follows:
added
What I would like is when this other button is pressed, its server-side event fires and then the dialog box fades away as with Close. Here’s the extra jQuery code I added:
$(‘#Button1′).click(function(evt) {
evt.preventDefault();
$(‘#EntryForm’).unblock({
onUnblock: function() {
$(‘#ConfirmSave’).remove();
}
});
});
But when I tried this, pressing “Test” caused an entire postback. Yet if I remove UseSubmitBehavior=”false” then the server-side event does not fire.
What should I do?
Robert
What you’re probably running into is that BlockUI shuffles things around in the DOM. So, your Button will no longer be caught as an async postback trigger by ASP.NET AJAX.
Is it possible that you could use a web service or page method call instead? That would be a lot easier to manage from within the modal.
There’s a problem to display image indicator when using blockUI Version 2.20, the progress-indicator was not displayed.
At first, implementing the example of the previous post I thought I wrote something wrong, so I decided to move on this second example and use the downloaded code, but the image indicator was still not displayed.
I changed blockUI plugin to version 2.09 and problem solved. I’m in my first steps with js/jQuery so I can’t see why this is happening.
HI Dave,
I am using a modal Dialog to allow users to send a message. The whole thing works beautifully. But I want to automatically close the dialog box once the message has been posted.
I have this code:
success: function(msg) {
$(this).dialog(‘close’);
},
But the dialog box just doesnt close. But if I put any other code there, it gets executed. I tried FireBug, but it keeps going into to jQueryUI scripts and those are never ending.
Any ideas?
Thanks,
Sampath
The problem is that this doesn’t refer to your element anymore in the callback. Cache it in a variable before the $.ajax() call and then use that variable to reference the element later in the callback.
Sampath, I came across a situation similar to yours and resolved it this way: http://mwtech.blogspot.com/2009/08/subtle-messagebox.html
Hope this helps,
Robert