I have met the problem before,I solve by:

 cliend side: 
               <Columns>
                <ISWebGrid:WebGridColumn Name="Checker"  IsRowChecker="true" >
            </ISWebGrid:WebGridColumn>
      ...................
                       </Columns>

server side:
protected void Button1_Click(object sender, EventArgs e)
        {     
          
            TextBox1.Text = "checked rows : \n";
            foreach (string keyValue in WebGrid1.RootTable.GetCheckedRows())
            {

                TextBox1.Text += WebGrid1.RootTable.Rows.GetRowByKeyValue(keyValue).Position + " ; \n";//current rowIndex                    
  
            }
        }

Hi,

Already ISRoWChecker=true is set for the checkbox.

Please let me know what else could be the reason.

Why Webgrid1.RootTable.Rows[i] is coming as null after doing the loadmore for the newly loaded rows after clicking the loadmore icon.

regards,

Madhavan 

Hello Madhavan,

I already created a simple sample and use a button to check the checkedRows. However, the collection looks just fine. Could you please replicate in my sample?

Hi Handy,

Please find the attached sample.
GetCheckedRows is returning correct count after the click of loadmore.

But the Webgrid.RootTable.Rows of the checked rows after click of loadmore is returning as null.

Webgrid.RootTable.rows.count is returning only the first page loaded rows and not the loaded rows count of second page.

Please see the attched replicated sample.

Regards,

Madhavan

Hi Madhavan,

This bug is only showed if you use SendCustomRequest.
FYI, you can try to alert the row, in IntializePostBack event and try to do refresh.
Notice that, the count goes wrong after SendCustomRequest.
I will report this to our developer team.

Regards,
Handy

Hi Handy,

Please tell us how to achieve our scenario.

Our scenario is we will be selecting the checkboxes on first page or after clicking on load more.

Then we will click on the Html button which is currently sending a custom request and in the initailize postback method we are doing the operation of adding our objects of the selected row into a cache and then opening the required window to act on it by using Webgrid1.ClientAction.InvokeScript from the Initialize postback method.

Please advice.It is urgent.

Thanks,

Madhavan

Hello Madhavan,

If you only want to get your selected row which you got from checkbox, you can instanly use GetCheckedRows().
ISRowChecker is used for multiple selection. So, every checked rows can be obtained with GetCheckedRows().

So, I don't get it why do you need to get rows count in your previous sample. The rows count you used, is  not to get checked rows.

Regards,
Handy

Hello Handy,

The GetCheckedRows Method is returning an ArrayList and the values are the Keyvalues (In the Replicated sample it is OrderId column value).For the Checkedrow i need CustomerId column value also.Can you please modify my replicated sample on how to do it. 

In Our Original Scenario it is Workitemid column value  for us. But we also need some other column values for the checked rows in our scenario we need workflow column value.That's why we need the Row object see the code below

Guid WorkitemId = new Guid(WebGrid1.RootTable.GetCheckedRows()[i].ToString());

string workflow = WebGrid1.RootTable.Rows[j].Cells.GetNamedItem("Workflow").Text;

Skelta.HWS.WorkItem workitem = new Skelta.HWS.WorkItem(new Skelta.Core.WorkflowObject(workflow, new Skelta.Core.ApplicationObject(_ApplicationName)), WorkitemId);

One more thing. We want to do this logic in Webgrids Initializepostback method.That's why we are doing the sendcustomrequest.

our scenario is after selecting the checkbox the multi select operation should happen without postback.

Please advice.

Regards,

Madhavan

Hello Madhavan,

My suggestion, if you want to get the other cell value of checked rows, you can use clientside method GetRowByKeyValue() method in clientside.
First, you will need to pass the KeyValue that you have obtained in serverside with GetRowsChecker().

Regards,
Handy

Hello Madhavan,

I got a response from our developer teams. However, this is not a bug but it is a default behaviour.