Why sorting and paging callback on GridView control fails after custom callback
Hello and welcome again. Today, I’d like to blog about another interesting case that we received. This case was based on the client scripts callbacks features in ASP.NET 2.0. If you do not know what script callback is, then you can click here to learn more about client script callbacks before further reading.
SCENARIO:
Environment:
- An ASP.NET 2.0 application that uses a GridView control.
- The GridView control has the EnableSortingAndPagingCallbacks property set to true.
- The Page class implements the ICallbackEventHandler interface.
- You have written code that makes a callback to load new data into the GridView control.
PROBLEM
Whenever your callback code loads the GridView control with a new set of data from your DataSource, the sorting and paging callback functionality of the GridView fails. To be more specific, an attempt to sort or page has no effect after a callback.
BEHIND THE SCENES
Developers use code within their callback methods that emits the client side HTML for the GridView control which is then sent to the client for making changes to the browser’s document object model using a client side JavaScript function. To successfully replace the resulting HTML, you need to identify the point in the browser’s document object model where you want the new HTML to be replaced so that the users see the new data. Typically developers embed the GridView control within a <div> tag so that they can replace the innerHTML property of the <div> which will accomplish this task.
Whenever ASP.NET renders a GridView control, it renders it as a <table> within an <div> tag. This <div> tag has no ID property set. However when you enable the sorting and paging callback property for the GridView control, ASP.NET generates an ID for the <div> tag which takes this form – “__gv” + GridView ID + __div”. So let’s say if your GridView control has an ID GridView1, then this becomes “__gvGridView1__div”. When you turn off sorting and paging callbacks, this ID is no longer generated by ASP.NET. The reason it needs an ID for sorting and paging callbacks is to determine the point in the browser’s document object model where it needs to replace the HTML that contains the sorted markup.
RESOLUTION
Apply the HTML returned as a result of the callback you made to the innerHTML property of the <div> tag generated by ASP.NET when Sorting and paging callback is enabled. Here’s how you can do it.
protected void Page_Load(object sender, EventArgs e)
{
ClientScriptManager Cm = Page.ClientScript;
String ContextID = "__gv" + GridView1.ID.ToString() + "__div";
String CallbackScript = "function CallServer(arg, context) {" +
ContextID + ".innerHTML = 'Loading...';" +
Cm.GetCallbackEventReference(this, "arg", "ServerResponseHandler", ContextID) +
";}";
Cm.RegisterClientScriptBlock(this.GetType(), "CallServer", CallbackScript, true);
}
Client Side Javascript Embedded in ASPX Page:
function ServerResponseHandler(result,context)
{
context.innerHTML = result;
}
I have also attached a sample created in VS2005, which uses data from an XML file that demonstrates this. Extract the files to a folder on the drive and then open and run it from within Visual Studio 2005 or create a virtual folder within IIS and browse to the default.aspx page.
NOTES:
Although this works perfectly, developers may get confused if they took a look at the ViewSource from the browser. All browsers out there will display the markup from when the page was rendered last or posted back. Since callback is not a Postback, this can be very confusing. However, note that the Document Object Model of the browser will still have the correct HTML markup or let’s say the corresponding markup to what the user has on the webpage after the callback. There is a tool available called <> that displays the document object model of the browser for the web page that you are looking at. You can download it from: