Locking the Screen During a PostbackBy Scott Mitchell
In a perfect world all web applications would be snappy and responsive, and there would be no such thing as lengthy postback waits. But in the real world there are plenty of scenarios that take seconds to complete. For example, when a user visits a travel booking site like Expedia and enters his origination and destination information, it's not unusual for it to take several seconds before the search results appear. Similarly, I've worked on applications where clicking a button dynamically generated and e-mailed a large PDF file, or that have needed to query a very slow database located in corporate offices halfway around the world. In such cases it was not uncommon for the user to have to wait several seconds between submitting the form and getting a response from the web server.
While browsers provide some feedback to the user that the form has been submitted and a response is forthcoming, these visual cues are usually in the margins of the browser and still allow the user to interact with the page, re-click the button, or interact with some other user interface element on the page. Most travel sites send the user to a "Please Wait While We Process Your Results..."-type page when they submit their query. This does two things: it provides the user with visual feedback that their submission was accepted, and it prohibits them from re-submitting their search query twice.
Locking the Screen Using Cascading Stylesheets (CSS)
Each HTML element on a web page includes a variety of display attributes, including height, width, color, borders, padding, and so on. A lesser-known attribute is the
z-indexattribute, an integer value that specifies the stack order of an absolutely positioned element. In short, you can use the
z-indexproperty to place an HTML element on top of all other HTML elements on the page. Given two elements on a page the element with a greater
z-indexvalue appears on top of one with a lesser
z-index value can be used to lock the screen and prevent the user from interacting with the other elements on the web page. This entails
creating an HTML element that is as wide and tall as the screen and has a
z-index value greater than all other elements on the page. Such
an element will overlay all other elements on the page and thereby prohibit the user from clicking links, buttons, or other user interface elements
beneath the overlay.
Consider the following simple example. This page contains some text, a textbox, a button, and a
<div> element. The
<div> element is absolutely positioned in the upper left corner and is 200 pixels wide and tall. It's
is greater than any other element on the page. Consequently, the
<div> element covers up the content beneath it. Try out the
live demo to interact with the page. As you can see, you can't get to the content beneath the overlay.
Note: Locking the screen simply prohibits the user from clicking the user interface elements in the browser window. It does not stop the user from clicking the Back button, reloading the page, or using any of the browser's other features.
We can lock the entire screen by creating a
<div> element that is as wide and tall as the entire screen (rather than just
200 pixels by 200 pixels). But rather than having the
<div> element displayed all the time (as in the above HTML example), we
instead only want the screen to be locked when the user performs some client-side action, such as submitting the form. Additionally, it would be nice
to display some a message like, "Your request is being processed..." when the screen is locked.
Locking the Screen In Response to a Client-Side Action
<div>element that locks the screen in the HTML example above is always displayed. What we want to do is have this element displayed only when the user clicks the "Click Me!" button. (The idea here is that when the user clicks the button the form will be submitted and the browser will refresh once the server returns its response. While we are waiting for that response we want to lock the screen. Therefore, by displaying the
<div>element when the button is clicked the screen will be locked until the response is returned from the web server, at which point the browser will display the new page.)
style attribute let's use CSS classes instead. The following demo includes two CSS classes:
LockOff- the initial CSS class setting for the
<div>element. This CSS class indicates that the
<div>element should be hidden.
LockOn- the CSS class that locks the screen. Note that this CSS class uses absolute positioning, a high
z-indexvalue, and stretches the
<div>element all the way across the screen. Moreover, it uses the
opacityattribute to let the user "see through" the
<div>element to the content behind it.
skm_LockScreen, which also sets the
innerHTMLattribute to the passed-in
skm_LockScreenfunction is called when the "Click Me!" button is clicked and displays the message, "We are processing your request..."
Wrapping This Functionality Into A Custom ASP.NET Base Page Class
Locking the screen requires adding HTML elements to the page (the "lock"
<div>element from server-side code. Moreover, by placing this functionality in a custom base page class it is possible to extend this behavior to all ASP.NET pages in your application. (For more information on creating and using custom base page classes, along with their benefits, be sure to read Using a Custom Base Class for your ASP.NET Pages' Code-Behind Classes .)
The code available for download at the end of this article includes such a custom base page class (
BasePage), which includes three
<div>elements to the page in order to lock the screen. This method is marked
Privateand therefore cannot be called from your ASP.NET pages; rather, it's used by the following two methods to ensure that the necessary screen locking mechanisms are in place.
LockScreenAfterClick(WebControl, message)- adds client-side script to the passed-in WebControl so that when the WebControl is clicked the screen is locked, showing message. Imagine that you wanted to lock the screen and show the message "Processing Your Request..." when the Button Web control
btnSubmitwas clicked. You would accomplish this by adding the following code to the
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
MyBase.LockScreenAfterClick(btnSubmit, "Processing Your Request...")
Note: In able to use the above code snippet the ASP.NET page's code-behind class must extend the custom base page. Also note that this method needs to be called on every visit to the page - the initial visit plus subsequent postbacks.
LockScreenAfterDDLChange(DropDownList, message)- much like
LockScreenAfterClick, this method locks the screen after the passed-in DropDownList control has been changed on the client-side. This is useful if you have a DropDownList control whose
AutoPostBackproperty is set to True and whose postback is typically long-running.
The following image shows the locked screen user interface after the Button is clicked. Note that the screen is grayed out and a message is displayed, "Processing Request..." As noted in the earlier examples on this page, while the screen is locked the visitor cannot interact with the user interface elements underneath the overlay.
This demo has been tested and operates as expected in Safari 3.2 (for PC), Firefox 3.0, Internet Explorer 7.0, and Google Chrome 1.0.
|Locking the Screen on a Partial Page Postback|
|The techniques discussed in this article focused on locking the screen in response to a full page postback. However, this technique can also be used in an Ajax-enabled application. For more information on locking the screen in response to a partial page postback see: Providing Visual Feedback with the UpdateProgress Control.|
While browsers provide some visual cues that a request has been sent to the server and that it is awaiting a response, these visual cues are in the periphery and do not inhibit the user from resubmitting the form or interacting with other user interface elements on the page. Many websites use some mechanism to lock the screen after the user has initiated a potentially long-running postback. Travel websites, for instance, have a separate "We're Processing Your Request..." type page.
element displayed in response to some client-side action. This
<div> element spans the width and height of the screen and overlays
the other HTML elements on the page, thereby prohibiting the user from resubmitting the form. It also serves as a more visible cue that the user's action
was received and that a response is forthcoming.