Hello,
If a GridClientSelectColumn column is included in a RadGrid that is bound client side, and the number of rows bound on the client exceeds the initial PageSize value, the check boxes are rendered in that column for the additional rows using a naming convention for the ids that can cause conflicts if multiple grids are included on the page and are bound in the same manner. The problem is compounded if RadFormDecorator is used after data binding to ensure that the new check boxes have a style that is consistent with the other controls on the page, in that clicking a check box on one grid may result in the check box of the same ordinal row of another grid to be checked, instead, because they share the same id.
Specifically, the naming convention used for the ids of the new check boxes is "[row number]_SelectCheckBox" which means that two grids that have both bound data client side may each have check boxes with the same id. The rendered id should include another component, such as the id of the grid, itself, to ensure the uniqueness of the id of each check box.
To replicate this issue, add two RadGrid controls to a page and include a GridClientSelectColumn in each. Set the "PageSize" to 1 to minimize the amount of unnecessary HTML rendered on the server and transmitted to the client, and set "AllowPaging" to false. Now, include logic to bind data to each of these grids, client side, where the number of items bound is greater than one. View the IDs of the rendered check boxes using something like FireBug and note that the ids of new check boxes are the same in both grids.
To exacerbate the example, set "AllowScroll" to true and "ScrollHeight" to 200px, bind 100 rows to each grid client side (simulating a list box, effectively), and then call RadFormDecorator's decorate client method, passing the grid's element as the element parameter. As a user of the page, don't touch the first grid, but instead scroll to the bottom of the second grid and click a check box. What you will encounter is that after clicking the check box the screen scrolls down REALLY FAR to where the check box of the same id in the first grid resides, but which is not visible since the clipping overflow is hidden. If you then go back to the first grid and scroll to the bottom of the list, you will find that the last check box of the first grid is now checked, while the check box you attempted to check in the second grid is not checked.
Please note that I don't want to set the initial "PageSize" arbitrarily high as a work around, because that will render too much HTML initially. I am using several RadGrid controls on a single page as list boxes, since the client side API of RadGrid is so beautifully robust and flexible allowing me to do some really nice things that would be very challenging to do with RadListBox. I'm sure I can get around the issue by rendering my own check boxes in a template column and forcing a special "check all" check box to be rendered in the header cell for that column, but I would like to avoid that hassle if possible.
If a GridClientSelectColumn column is included in a RadGrid that is bound client side, and the number of rows bound on the client exceeds the initial PageSize value, the check boxes are rendered in that column for the additional rows using a naming convention for the ids that can cause conflicts if multiple grids are included on the page and are bound in the same manner. The problem is compounded if RadFormDecorator is used after data binding to ensure that the new check boxes have a style that is consistent with the other controls on the page, in that clicking a check box on one grid may result in the check box of the same ordinal row of another grid to be checked, instead, because they share the same id.
Specifically, the naming convention used for the ids of the new check boxes is "[row number]_SelectCheckBox" which means that two grids that have both bound data client side may each have check boxes with the same id. The rendered id should include another component, such as the id of the grid, itself, to ensure the uniqueness of the id of each check box.
To replicate this issue, add two RadGrid controls to a page and include a GridClientSelectColumn in each. Set the "PageSize" to 1 to minimize the amount of unnecessary HTML rendered on the server and transmitted to the client, and set "AllowPaging" to false. Now, include logic to bind data to each of these grids, client side, where the number of items bound is greater than one. View the IDs of the rendered check boxes using something like FireBug and note that the ids of new check boxes are the same in both grids.
To exacerbate the example, set "AllowScroll" to true and "ScrollHeight" to 200px, bind 100 rows to each grid client side (simulating a list box, effectively), and then call RadFormDecorator's decorate client method, passing the grid's element as the element parameter. As a user of the page, don't touch the first grid, but instead scroll to the bottom of the second grid and click a check box. What you will encounter is that after clicking the check box the screen scrolls down REALLY FAR to where the check box of the same id in the first grid resides, but which is not visible since the clipping overflow is hidden. If you then go back to the first grid and scroll to the bottom of the list, you will find that the last check box of the first grid is now checked, while the check box you attempted to check in the second grid is not checked.
Please note that I don't want to set the initial "PageSize" arbitrarily high as a work around, because that will render too much HTML initially. I am using several RadGrid controls on a single page as list boxes, since the client side API of RadGrid is so beautifully robust and flexible allowing me to do some really nice things that would be very challenging to do with RadListBox. I'm sure I can get around the issue by rendering my own check boxes in a template column and forcing a special "check all" check box to be rendered in the header cell for that column, but I would like to avoid that hassle if possible.