I'm attempting to use the Row.DataChanged property to control updates to our database, but I must not full understand how it works. Any suggestions would be appreciated.
We bind a dataset to a grid and display it. The user is allowed to make changes (modify, add, delete). When the user has finished, they click a Save button. The Save button server-side implementation does the actual database updates. We don't want to update the database until Save is clicked.
The Save implementation iterates over Grid.Rows looking at DataChanged for each row. This works fine for Unchanged, Added and Modified rows. However, Deleted rows are gone from Grid.Rows so we can't capture those changes. The documentation for DataChanged seems to indicate that all four row states should be possible.
What am I missing? Do Deleted rows only show up for certain types of data sources? Do Deleted rows ever show up? I'd really like to avoid caching the data to determine what was deleted, but that seems like the next step. Any other suggestions?
Thanks,
DaveL
A PS to this old thread which I found whilst searching for info on the DataChanged property ...
It appears that the Add/UpdateRow and Add/UpdateRowBatch events fire on all postbacks and are sequenced to fire before the button click events. If you need to selectively fire these events for a particular button click you can workaround the ordering by examining the Request.Form collection and wrapping it in a property for the page, e.g.:
'---------------------------------------------------------------------------- ' UpdateButtonPressed - True if the Update Button has been pressed '---------------------------------------------------------------------------- Public ReadOnly Property UpdateButtonPressed() As Boolean Get Return (Not IsNothing(Request.Form(btn_Update.UniqueID))) End Get End Property
This might help with getting the IG update and add events to fire only when you want them to.
To let you know how I got around this functionality is I ended up adding functionality to all of our grids that add a hidden column to the grids that handles the datachanged properties through javascript. This will also persist through postbacks until the grid is rebinded. It seems a bit rediculous but it was the only way to maintain datachanged properties through multiple postbacks for our grids.
My suggestion to infragistics is to maintain DataChanged properties until the grids are rebinded and the user has viewstate enabled for their grid. If people do not use viewstate in their grids then they should have to implement their own version of DataChanged with some other state management implementation.
Obviously the deleted rows are being saved in the grid's initial postback. Is there anyone to access this deletedRows collection via the server side? It seems as though only being able to grab the rows via the batch events is a pretty worthless thing if you can have other functionality happening on your page.
Were having the same issue. Why even have DataChanged.Deleted if you can't check for it?
We tried implementing the RowBatch events but they fire no matter what postback is occuring. There are times when we perform a postback when we don't want grid changes to be persisted. We have a "Cancel" button for instance. If the user clicks cancel, we do a postback to reload the page. In this instance, the RowBatch events are fired. In our case, it is more efficient to loop the grid rather than having non-saving postback events fire off these events.
All postbacks are fired from either a UltraWebMenu or a UltraWebToolbar click. Unfortunately, the postback events of the UltraWebMenu and UltraWebToolbar happen after the RowBatch events have fired so we can't figure out how to identify which UltraWebMenu was selected before the RowBatch has fired.