http://www.codedigest.com/Articles/ASPNETAJAX/125_Using_UpdateProgress_Control_Effectively.aspx
http://stackoverflow.com/questions/996957/why-does-update-progress-does-not-fire-when-associatedupdatepanelid-is-set
Using UpdateProgress Control Effectively
Introduction
UpdateProgress control provides a mechanism where we can inform user that the server side processing is still progressing in ASP.NET AJAX applications. For example, we can provide a “Loading…” message or an image showing the progressing of the request. Just dragging an UpdateProgress control into an ASP.Net AJAX page and specifying its ProgressTemplate will do its job. This article will give you more inputs on how to use the UpdateProgress control very effectively in our projects. Before moving to our subject matter, we will see the use of UpdateProgress control by implementing its default behavior.
Using UpdateProgress Control
When we click on any operation on the page, the image will be displayed as an indication to the users for progressing
The image which is displayed in the page is inside the UpdateProgress control. Moving forward, we will some advanced usages of UpdateProgress control in this article.
Displaying a Cancel button to Cancel the Asynchronous Postback with UpdateProgress control
When notifying about the progress of the asynchronous request to the user, it will be good if we have option to cancel the request. This can be done through the UpdateProgress control and abortPostBack() method of PageRequestManager class. The below JavaScript function will help us do that.
function CancelPostBack() {
var objMan = Sys.WebForms.PageRequestManager.getInstance();
if (objMan.get_isInAsyncPostBack())
objMan.abortPostBack();
}
To call this function, include a HTML button in the UpdateProgress control and call the above method in onclick event.
If we execute the page, we can see the cancel button appearing which will cancel the postback and the results in no refresh of contents on the update panels
Drawback of the above approach
In the above approach, the abortPostBack() function will cancel only the update/refresh of UpdatePanel control and thus, whatever serverside processing is initiated will not be aborted. Hence, the server side processing will move forward and completes its execution, but the actual results will not be updated in the update panel.
It is advisable to use this functionality when there are no persisting operations like database operations, etc done on the server. It can be used to cancel some simple operations like loading controls, etc dynamically depending on some server side business rules.
Associating a UpdateProgress Control to a UpdatePanel
If we see the implementation in previous sections, the UpdateProgress control will be enabled for every asynchronous postback originated from any where in the page. It is possible to limit to the UpdateProgress control to be enabled only for the asynchronous postback originated from a particular UpdatePanel control. To do this, there is a property called AssociatedUpdatePanelID which accepts an UpdatePanel control ID present on the page. Setting this Property will enable the UpdateProgress control only for the postback originated from the particular UpdatePanel.
The drawback of this approach is, it will not enable the UpdateProgress control for a postback caused by an external trigger of the UpdatePanel. It is by design of this property AssociatedUpdatePanelID. The Implementation of enabling the UpdateProgress control is done by moving through the control hierarchy in UpdatePanel control identified via AssociatedUpdatePanelID to find a match for the control that causes the actual postback. Since, the external triggers will not be present in the hierarchy it will not enable the UpdateProgress control.
This drawback can be prevented by injecting a simple JavaScript code. For example, if we have a external trigger (btnClear) to a UpdatePanel control(UpdatePanel1). We can enable the UpdateProgress control for the postback caused by btnClear manually by the following JavaScript function.
function pageLoad()
{
var manager = Sys.WebForms.PageRequestManager.getInstance();
manager.add_endRequest(endRequest);
manager.add_beginRequest(OnBeginRequest);
}
function OnBeginRequest(sender, args)
{
var postBackElement = args.get_postBackElement();
if (postBackElement.id == 'btnClear')
{
$get('UpdateProgress1').style.display = "block";
}
}
The UpdateProgress control will be rendered as a DIV tag and can be enabled by setting its display CSS property to block by hooking in from OnBeginRequest() event of PageRequestManager object. Through this approach, it is possible to enable different UpdateProgress control for different postback element on the page.
A Simulation to Disable Page Elements and Display UpdateProgress Control
If the server side operation is really time consuming and if the user clicks the page elements again and again for response, the PageRequestManager class will cancel the current request and sends a new request to the server for every click. From the previous sections, we understood that canceling a postback through PageRequestManager class will prevent the panel updations/refresh but the actual server side processing will be continued. To prevent this, we can either disable the page elements until a response is received or allow one postback at a time. If the number of control in the page is more then it will become cumbersome to disable/enable page elements for every request/response.
We can simulate a behavior where we can make the page look like disabled but it’s actually not. Refer the below figure.
To do this, we can include the whole content of the page inside a DIV tag(ParentDiv) and apply some css rules which make the DIV partially opaque by applying a CSS class from OnBeginRequest event. In the same way, we can revert back the CSS rules in endRequest() event.
.Background
{
position: fixed;
left: 0;
top: 0;
z-index: 10;
width: 100%;
height: 100%;
filter: alpha(opacity=40)
}
function pageLoad()
{
var manager = Sys.WebForms.PageRequestManager.getInstance();
manager.add_endRequest(endRequest);
manager.add_beginRequest(OnBeginRequest);
}
function OnBeginRequest(sender, args)
{
$get('ParentDiv').className ='Background';
}
function endRequest(sender, args)
{
$get('ParentDiv').className ='';
}
//Page contents go here
When executed, this will give the illusion that the page is disabled similar to the above figure and the user will understand the processing is going on. To increase/decrease opacity of the page, adjust the value of “filter:alpha(opacity=40)” in Background CSS class.
Implemented Code
function pageLoad() {
var manager = Sys.WebForms.PageRequestManager.getInstance();
manager.add_beginRequest(OnBeginRequest);
manager.add_endRequest(OnEndRequest);
}
function OnBeginRequest(sender, args) {
var postBackElement = args.get_postBackElement();
$get('ctl00_UpdateProgress2').style.display = "block";
}
function OnEndRequest(sender, args) {
if (args.get_error() != undefined) {
var mymessage = "";
if (args.get_error().message.indexOf("iGurukulSecurity") != -1) {
mymessage = "You don't have required Security Permission";
$get('ExceptionBy').innerHTML = 'Security';
}
else {
mymessage = "Oops..\n An error has occured while trying to process your request." + args.get_error().message;
$get('ExceptionBy').innerHTML = 'Error';
}
$get('divMessage').innerHTML = mymessage;
$get('ExceptionBy').style.visibility = "hidden";
$get('Error').style.visibility = "visible";
$get('overlay').style.visibility = "visible";
args.set_errorHandled(true);
}
$get('ctl00_UpdateProgress2').style.display = "none";
}
function CloseError() {
if ($get('ExceptionBy').innerHTML != 'Security') {
location.reload(true);
}
// Hide the error div.
$get('ExceptionBy').innerHTML = '';
$get('divMessage').innerHTML = '';
$get('Error').style.visibility = "hidden";
$get('overlay').style.visibility = "hidden";
}
No comments:
Post a Comment