Hi -
I've got an UnboundCheckBoxField as a column in a WebDataGrid. I want to use this to track edits to the grid row. I am capturing the CellValueChanging event and calling my javascript function to then set the value of the check box for that row. I am able to use the cell._setCheckState(true); to set the check state of the cell, but if I try to do cell.set_value(true); I get an overflow error.
If I only do the _setCheckState(true), the checkbox displays correctly, but when I loop through the rows collection in the code behind during a post back, the cell value is false. Oddly enough, if I actually click on my check box in the grid and trigger a post back, the cell value is true. There's got to be a way to set the value of that check box through Javascript so that the value is set just as if it was clicked on, but beats me if I can figure it out.
Thanks,
Jeff Balcerzak
Hi Jeff,
This happens because you call set_value in cellValueChanging client event. When you call set_value, it triggers that same event, so you get an overflow error. You could either switch to handling cellValueChanged or cell._set_value_internal(true, 1).
regards,David Young
Actually on second thought, the same overflow might happen if you use set_value in the changed event. You might need a flag in your event to check the key. If the key is the unboudn checkbox key, do not call set_value on that cell. That should fix the recursion problem.
-David Young
That checks the box fine in the grid, but the value does not persist during a post back - its really odd.
If you do not use set_value, I do not think it will persist as part of editing core. You need to use that and only call that line of code if the key of the column whose cell just changed was not the unbound checkbox, as I said in my second post.
Dave
Hi Dave -
Wasn't following at first - didn't realize that changing the value of the checkbox via javascript would actually raise the cell changing event again - makes sense now, if you don't wrap the set_value call with an if statement, you setup a race condition and blow things up. Happy to say its persisting the value now, and I am able to see it in the code behind when I write the data back to the server.
thanks for your help,
Jeff