Question

This probably looks like a duplicate but I don’t think so. I have already searched stackoverflow, may be not enough.

Here is my challenge:

<asp:LinkButton runat="server" ID="DeleteRow" CommandName="deleterow" 
   CommandArgument='<%# Eval("ID") %>' Text="Delete" 
   OnClientClick="return confirm('Are you sure you want to delete this record?');" /> 

If you click the link the first time, OnRowCommand is not fired. When you click it the second time, it works.

I looked at the source and I have these differences.

//When you first load the page: the GUID is the PK for that row 
1. javascript:__doPostBack('ctl00$content$gvSchoolClasses$58fd1759-f358-442e-bf73-2e9cedfc27e8$DeleteRow','')

//After the link was clicked the first time, the link changed and the ID empty, but works
2. javascript:__doPostBack('ctl00$content$gvSchoolClasses$ctl02$DeleteRow','')

I copied the two codes from the href of the asp:LinkButton for BEFORE and AFTER click.

What is wrong? I only have one other event on my page RowDataBound.

  protected void gvSchoolClasses_RowDataBound(object sender, GridViewRowEventArgs e)
  {
        e.Row.ID = Guid.NewGuid().ToString();
  }

  protected void Page_Load(object sender, EventArgs e)
  {
        CheckAuthentication();

        if (!Page.IsPostBack)
        {
            ClassesAcademicYearLabel.Text = "- Year " + Setting.Year;
            //FillClassesList();  //filling some combo boxes. Have checked the codes here too
            //FillLettersList();  //they didn't affect the Grid
            FillGrid();
        }

        ClassErrorLabel.Visible = false;

  }

Answer 1

By setting the ID property of the row in the RowDataBound event, you’ve created the problem you’re observing.

Since the RowDataBound event isn’t fired until after the page’s controls have already been added to the collection, ASP.NET doesn’t have a way to update the already-computed client references. Hence, the command doesn’t get fired in the way you’re expecting.

I’ve noticed that you’re already setting the CommandArgument property to the ID generated in the RowDataBound event, which could also be part of your problem (depends on order of events firing; I don’t have a pipeline chart handy).

EDIT: a quick fix for this could be to simply set the ClientID properties (sorry, not the exact name, but intellisense should get you the rest of the way to it) to some sort of Manual, not Auto determination. That way, the ID you set is never changed by the framework.

To elaborate a bit more on why you’re seeing this problem, consider the client-side id’s presented:

ctl00$content$gvSchoolClasses$ctl02$DeleteRow

This ID is guaranteed to be unique (for this page) by taking the declared ID (DeleteRow) and successively walking UP the control hierarchy and prepending parent ID’s to the string. JS code can be confident that passing this string to getElementById will behave in a consistent, predictable manner.

In order to be able to generate said ID, all of the controls in the hierarchy must already be present and accounted for by the rendering engine.

Now let’s consider what happens when that the ID property of a control is changed (note this is not the ClientID, but simply the property with a name of ID).

ctl00$content$gvSchoolClasses$58fd1759-f358-442e-bf73-2e9cedfc27e8$DeleteRow

You’ll note that instead of the row’s naming container (cl02), it now has the GUID you generated and assigned to it. Client JS attempting to access this container using the previously assigned ID will be disappointed, since it will no longer work as expected!

When an ASP.NET control fires a post-back via a call to javascript:__doPostBack('ctl00$content$gvSchoolClasses$58fd1759-f358-442e-bf73-2e9cedfc27e8$DeleteRow','')

the post-back will occur just fine and dandy, but (and you can verify this by inspecting the form params of the postback) when the server processes the request, it will attempt to rehydrate (from viewstate) a control that doesn’t exist. Consequently, it will create a new instance of the control (with the correct ID) which has no idea that a command has been issued, so the XXXCommand event(s) are never fired. Since databinding isn’t happening (it’s a postback, and your code correctly checks for that condition), the ID is never reset, and the command can be fired normally