Alessandro Zifiglio : gridview

Custom Serverside paging in GridView Vs DataGrid

alessandro — Tue, 09 Oct 2007 15:29:00 GMT

When doing serverside paging(that is paging at the database layer by returning only the paged result), one of the things I miss in the GridView control is the VirtualItemCount, which is supposedly only supported in the older control's like the DataGrid.

This property was quite useful because while being able to supply to the DataGrid a variable number of paged result sets, i was also able to tell the DataGrid, the total number of records, that way it knew how many pager buttons to display.

Eg. If we had, say a total of a 100 records and had the pageSize set to 7, so only 7 records are shown at a time, then how does the grid know how many numbered pager buttons to display allowing us to navigate from one page to another ? That's where the VirtualItemCount came into play and saved the day. To this property we'd pass a total records count and that was it. In the GridView today ? There is no VirtualItemCount present. The way it were planned it seems is to use the ObjectDataSource, which in my honest opinion is simply extra work, however it does abstract much of this code nicely and put it where it should be, in the data tier.

In all the example code in this post, I shall be using the MemberShip.GetAllUsers method. This method is overloaded and can retrieve a paged result of users Versus returning all the user's in the database, which is a quite handy overload and works out nicely for the code i want to use in this post.

Let's look at a simple example of how we couldof performed custom paging on the DataGrid control back in the old days :

int virtualItemCount = 0;
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
        {
            DataGridMembers.DataSource = Membership.GetAllUsers(0, 
        DataGridMembers.PageSize, out virtualItemCount);
            DataGridMembers.VirtualItemCount = virtualItemCount;
            DataGridMembers.DataBind();
        }
    }

Note the VirtualItemCount ? Then on the PageIndexChanged event of the DataGrid we did :

protected void DataGridMembers_PageIndexChanged(object source, 
    DataGridPageChangedEventArgs e)
    {
        DataGridMembers.CurrentPageIndex = e.NewPageIndex;
        DataGridMembers.DataSource = Membership.GetAllUsers(e.NewPageIndex, 
    DataGridMembers.PageSize, out virtualItemCount);
        DataGridMembers.DataBind();
    }

And that was it, it was as simple as that :-)

Now try to do that on the GridView ? Can't be done and this is a control that is replacing the old DataGrid control. To make things worse, the DataGrid is not a supported control anymore in 2.0 ; It's been obsoleted and by default you wont even find this control in your toolbox. You can still use it however by manually adding it to your toolbox. Unfortunate, because there are moments like this custom paging situation and i'm getting nostalgic already.

So, how to achieve the same thing in the GridView control which happens to replace the DataGrid ? Well, it's a long shot. Since we cannot achive this directly on the GridView, we are going to have to do it via the DataSource control, which is actually the control that is populating the data for the gridview and also the control that handles paging and sorting amoung other things. While i like this kind of data abstraction, i'm actually doing more work and making the extra effort,but this is how you would implement custom paging on your GridView control.

The GridView alone is lacking a VirtualItemCount property, which i believe shouldn't have been so hard to implement. To compensate for this lacking, you perform custom serverside paging by using an ObjectDataSource control, defining a SelectMethod and a SelectCountMethod method. The SelectCountMethod is your custom method that returns the Total records count.

So let's look at some code, and there are few gotcha's that weren't exactly obvious to me in the begining :
First our custom SelectMethod :

public MembershipUserCollection GetAllUsers(int startRowIndex, 
    int maximumRows)
    {
        if (startRowIndex > 0)
            startRowIndex = startRowIndex / maximumRows;
        return Membership.GetAllUsers(startRowIndex, 
            maximumRows, out selectCountValue);
    }

One gotcha you want to make note of is how i have some extra code to divide startRowIndex by maximumRows ; This is because startRowIndex is actually the first row in the resultset as the variable name indicates, however what i really need is the current page index, because that is what our stored procedure is expecting, in this case that is what the internal MemberShip.GetAllUsers method is expecting.

Next we need to add a SelectCountMethod :

int selectCountValue = 0;
    public int SelectVirtualCount()
    {
        return selectCountValue;
    }

The code is minimum as you can note, but ofcourse, there is some extra effort to making the abstraction. The code above goes into the data layer.

And lastly, we need to subscribe to PageIndexChanging event of our GridView and pass the selected page index :

protected void GridViewMembers_PageIndexChanging(object sender, 
    GridViewPageEventArgs e)
    {
        GridViewMembers.PageIndex = e.NewPageIndex;
    }

A peculiar behaviour you will notice is that the SelectCountMethod and the SelectMethod both share the same SelectParameters if SelectParameters are defined. Peculiar because i was not really expecting it, however I have no issues with it, For example if we had to rewrite our previous example to include also a search by userName, then our ObjectDataSource would be expecting some SelectParameters like this :

<asp:ObjectDataSource ID="ObjectDataSourceMembers"
        EnablePaging="True"
        SelectCountMethod="SelectVirtualCount"
        SelectMethod="GetAllUsers"
        TypeName="MembersData" 
        runat="server">
<SelectParameters>
            <asp:ControlParameter ControlID="TextBoxUserName" Name="userName" 
        PropertyName="Text" DefaultValue="All" />
        </SelectParameters>
</asp:ObjectDataSource>

And then modified our SelectMethod as such :

public MembershipUserCollection GetAllUsers(int startRowIndex, 
int maximumRows, string userName)
    {
        if (startRowIndex > 0)
            startRowIndex = startRowIndex / maximumRows;
        if (userName == "all")
        {
            return Membership.GetAllUsers(startRowIndex,
                maximumRows, out selectCountValue);
        }
        else
        {
                return (MembershipUserCollection)
                    Membership.FindUsersByName(userName + "%", 
                    startRowIndex, maximumRows, out selectCountValue);
        }
    }

As you can see while our GetAllUsers(SelectMethod) has the needed userName parameter, our SelectVirtualCount method defined above does not have any parameters defined on it, since we don't need to pass it anything. However, the ObjectDataSource is going to complain with :

ObjectDataSource 'ObjectDataSourceMembers' could not find a non-generic method 'SelectVirtualCount' that has parameters: userName

So it means both the SelectMethod and the SelectCountMethod share the same Select parameters. I resolved by adding the extra userName parameter in the SelectCountMethod as well, while i did not clearly need it, but no big deal.
Here is what the modified SelectCountMethod wouldof looked like :

int selectCountValue = 0;
    public int SelectVirtualCount(string userName)
    {
        return selectCountValue;
    }

The SelectCountMethod is treated exactly in the same way the SelectMethod is treated, so the ObjectDataSource's Selected Event is going to fire twice for example, once when the SelectMethod is called and once when the SelectCountMethod is called. These are all gotchas i was not really prepared for.

Full code for custom serverside paging in DataGrid :

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">

int virtualItemCount = 0;
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack)
        {
            DataGridMembers.DataSource = Membership.GetAllUsers(0, 
        DataGridMembers.PageSize, out virtualItemCount);
            DataGridMembers.VirtualItemCount = virtualItemCount;
            DataGridMembers.DataBind();
        }
    }

    protected void DataGridMembers_PageIndexChanged(object source, 
    DataGridPageChangedEventArgs e)
    {
        DataGridMembers.CurrentPageIndex = e.NewPageIndex;
        DataGridMembers.DataSource = Membership.GetAllUsers(e.NewPageIndex, 
        DataGridMembers.PageSize, out virtualItemCount);
        DataGridMembers.DataBind();
    }

</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    <asp:DataGrid ID="DataGridMembers" AllowPaging="True" 
        AllowCustomPaging="true" PageSize="2" runat="server" 
        OnPageIndexChanged="DataGridMembers_PageIndexChanged">
        <PagerStyle Mode="NumericPages" 
                     HorizontalAlign="Right" />
        </asp:DataGrid>
    </div>
    </form>
</body>
</html>

And the full code for custom paging in GridView :

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">

protected void GridViewMembers_PageIndexChanging(object sender, 
    GridViewPageEventArgs e)
    {
        GridViewMembers.PageIndex = e.NewPageIndex;
    }

</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        
        <asp:GridView ID="GridViewMembers" DataSourceID="ObjectDataSourceMembers" 
    runat="server" AllowPaging="True" PageSize="2" 
    OnPageIndexChanging="GridViewMembers_PageIndexChanging">
        </asp:GridView>
        <asp:ObjectDataSource ID="ObjectDataSourceMembers"
        EnablePaging="True"
        SelectCountMethod="SelectVirtualCount"
        SelectMethod="GetAllUsers"
        TypeName="MembersData" 
        runat="server"></asp:ObjectDataSource>
    </div>
    </form>
</body>
</html>

public class MembersData
{
    public MembersData()
    {
        //
        // TODO: Add constructor logic here
        //
    }
    int selectCountValue = 0;
    public int SelectVirtualCount()
    {
        return selectCountValue;
    }
    public MembershipUserCollection GetAllUsers(int startRowIndex, 
    int maximumRows)
    {
        if (startRowIndex > 0)
            startRowIndex = startRowIndex / maximumRows;
        return Membership.GetAllUsers(startRowIndex, 
            maximumRows, out selectCountValue);
    }
}

ImageButton Control nested in a GridView Control throws EventValidation error.

alessandro — Sun, 30 Sep 2007 22:54:00 GMT

Ever try to include an ImageButton control in your gridview and then end up with the following beautiful error message :

Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Thats right, its an EventValidation issue. This also occurs only with an ImageButton nested in a gridview. Moreover, you must be calling DataBind on the gridview if its a postback as well. Code speaks a thousand words, so lets look an example when this could occur :

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">

 1 protected void Page_Load(object sender, EventArgs e)
 2     {
 3         //if (!IsPostBack)
 4         //{
 5             BindGrid();
 6         //}
 7     }
 8     private void BindGrid()
 9     {
10         ArrayList al = new ArrayList();
11         al.Add("a");
12         al.Add("b");
13         al.Add("c");
14         GridView1.DataSource = al;
15         GridView1.DataBind();
16     }
17 
18     protected void ImageButton1_Click(object sender, EventArgs e)
19     {
20     }

</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    
    <asp:GridView  ID="GridView1" runat="server" OnRowDataBound="GridView1_RowDataBound">
    <Columns>
    <asp:TemplateField>
    <ItemTemplate>
        <asp:ImageButton ID="ImageButton1" OnCommand="ImageButton1_Click" runat="server" />
    </ItemTemplate>
    </asp:TemplateField>
    </Columns>
    </asp:GridView>
     </div> 
    </form>
</body>
</html>

As you can see from the following sample code, we are rebinding our grid even on a postback, this means when the user posts back via our ImageButton, the grid will get rebound again. When this happens the gridview will recreate the gridview Vs pulling values from viewstate. By calling DataBind again in the page_load method, the Gridview recreates the child controls, and by the time our page gets to the Postback event handling phase, RaisePostBackEvent is fired in our imagecontrol(since it implements the IPostBackEventHandler interface). RaisePostBackEvent is what calls the ValidateEvent method, with two arguments. 1st argument is the UniqueID of our ImageButton and the second argument is a string argument. The issue here is with the UnqiueID argument. It has the id of the wrong control. How, why, I dont know exactly. I just know that by the time the ImageControl reaches the render phase, it has the correct uniqueID again. Since the gridview is a templated control, it prefixes the control with a unique namespace which happens to be the rowID of the current row which gets appeneded along with the gridview's id. Its this row id going wrong somehow only during RaisePostBackEvent. Happens only with the gridview too. I have tested with a repeater for eg and this worked correctly without issues. The 3-4 possible solutions I can think of are :

1. Put an IsPostBack check and only bind the gridview if its a postback. This means the gridview will be repopulating from viewstate which obviously does not have this wrong rowid issue. So if you remove the comments from our previous code, your set. But not always populating from viewstate might be an option.

2. You can try setting a unique id for the row generated by the ItemTemplate in our gridview. YOu can try this in either the RowCreated method or the RowDataBound method. In this manner we do not depend anymore on INamingContainer generating a uniqueID for the row, which in turn gets prefixed on our control since the row is now the direct NamingContainer and the problem is solved, eg :

1 protected void GridView1_RowCreated(object sender, GridViewRowEventArgs e)
2 {
3 if (e.Row.RowType == DataControlRowType.DataRow)
4 e.Row.ID = e.Row.RowIndex.ToString();
5 }

and a 3rd way to work around this problem is to rebind the gridview at a later stage, a stage after RaisePostBackEvent has finished executing. Since EventValidation is called during this stage, its safe to rebind after this call. Meaning for eg, in the OnCommand/onclick event of our ImageButton or in the RowCommand method of the gridview. In short, calling rebind on the grid after the Postback event handling phase will resolve your issues. Also note that this issue is there only with the ImageButton, the same does not happen if you used a LinkButton for eg, or a Button control.

And yet a 4th way to work around this is to use a LinkButton control and nest an image in it making it behave like an ImageButton.

So why does this happen only with the ImageButton control ? This is because the ImageButton implements IPostBackDataHandler interface. Image elements unlike other form elements include the x,y co-ordinates location in the image where you clicked. In order to detect this change and raise an event, the ImageButton control needs to provide implementation for LoadPostData method. Also this is the same place where a call is being made for RegisterRequiresRaiseEvent. RegisterRequiresRaiseEvent is also the cause of the issue here. Without this call we have no problems with the uniqueID of the ImageControl, which is what made EventValidation to choke because the control was registered for EventValidation with one ID and then checked for Validation after validation with another ID. For me this unusual behaviour is a bug. We can make a simple test as the code that follows and the output of that code is not surprisingly the following and in this order :

LoadPostData: GridView1:_ctl2:ImageButton1
RaisePostBackEvent: GridView1:_ctl4:ImageButton1
AddAttributesToRender: GridView1:_ctl2:ImageButton1

Notice how in RaisePostBackEvent, the id of the control has changed magically and is now GridView1:_ctl4:ImageButton1. RaisePostBackEvent is also the method that registers the control for EventValidation. Notice that in a later phase AddAttributesToRender, the control id is back again to what it was, and this is also asif by magic! For me this is a bug. Also the cause is none other than the call being made to RegisterRequiresRaiseEvent from within LoadPostData, which you can test by following the inline comments i have included in the LoadPostData method.

Following is the code to verify this behaviour :

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls; 

namespace Test
{
/// <summary>
/// Summary description for CustomImageButton
/// </summary>
[SupportsEventValidation]
public class CustomImageButton : ImageButton
{
public CustomImageButton()
{
//
// TODO: Add constructor logic here
//
} 

protected override bool LoadPostData(string postDataKey, System.Collections.Specialized.NameValueCollection postCollection)
{
HttpContext.Current.Response.Write("<br/>LoadPostData: " + this.UniqueID);
return base.LoadPostData(postDataKey, postCollection);
// The reason this control chokes is because of the call being made to RegisterRequiresRaiseEvent.
// To test this, first commentout the call to 
// return base.LoadPostData(postDataKey, postCollection); above and then
// remove the following comments below and and try it. It will work without issues!
/*if (this.Page != null)
{
this.Page.RegisterRequiresRaiseEvent(this);
} 

return false;*/
}
protected override void RaisePostBackEvent(string eventArgument)
{
HttpContext.Current.Response.Write("<br/>RaisePostBackEvent: " + this.UniqueID);
// base.RaisePostBackEvent is what actually registers this control for EventValidation
// so dont call it in order to test this unexpected behaviour, otherwise, event
// validation will occur and you will get an error ofcourse :D
//base.RaisePostBackEvent(eventArgument);
}
protected override void AddAttributesToRender(HtmlTextWriter writer)
{
HttpContext.Current.Response.Write("<br/>AddAttributesToRender: " + this.UniqueID);
base.AddAttributesToRender(writer);
}
}
}