Does anyone have a CRUD example that works on sizable data sets?
I've been banging my head against this for a couple of weeks.
DataForm won't work - it's sequential, one-record-at-a-time interface is too tedious for more than a half-dozen records.
In-cell editing in GridVIew won't work - if the records have more fields than can be displayed in a row.
Using the DataForm as row-detail for a GridView shows promise, but the example doesn't show how to handle inserts, deletes, or save confirmations, or how to handle failed updates.
Using a DataForm Synchronized with a GridView also shows promise, but it works in a way that simply won't work, for the usual business cases.
Take a look at the "DataForm ICollectionView Synchronization" demo. It's really neat how you can navigate in the form and see the current row in the grid change, and vice versa.
Now try editing a row. Change a name. But don't click OK or Cancel, select a different row in the grid. Or click a prev/next button in the DataForm.
What happened to the data? If you go back to it, it looks like the form did an implicit OK.
If you were listening for the DataForm's EditEnding event, so you could update the database, and return Cancel = true, if something went wrong, sorry. EditEnding never fired. The database wasn't changed, but the grid and the form and the underlying collection were.
So maybe we're supposed to update the database from within the collection or the record objects. Well we can't do it from within the record's EndEdit() method, because from there we have no way of knowing whether we should be doing an insert or a delete.
So maybe we need to be looking at the collection's CurrentChanging event?
Digging into this, it seems that a QueryableCollectionView has a CurrentAddItem and a CurrentEditItem - and if we set e.Cancel = true if either of these is non-null, we can prevent the form from moving to a new record - but this doesn't stop the grid from moving to a new record. And, oddly enough, if you edit a field in the grid, then select a new row, CurrentChanging fires, but CurrentEditItem is null.
So we're back where we started - with a set of demos that show of some really nice glitz, but have enormous holes when it comes to building something that is actually useful.
I've been banging my head against this for a couple of weeks.
DataForm won't work - it's sequential, one-record-at-a-time interface is too tedious for more than a half-dozen records.
In-cell editing in GridVIew won't work - if the records have more fields than can be displayed in a row.
Using the DataForm as row-detail for a GridView shows promise, but the example doesn't show how to handle inserts, deletes, or save confirmations, or how to handle failed updates.
Using a DataForm Synchronized with a GridView also shows promise, but it works in a way that simply won't work, for the usual business cases.
Take a look at the "DataForm ICollectionView Synchronization" demo. It's really neat how you can navigate in the form and see the current row in the grid change, and vice versa.
Now try editing a row. Change a name. But don't click OK or Cancel, select a different row in the grid. Or click a prev/next button in the DataForm.
What happened to the data? If you go back to it, it looks like the form did an implicit OK.
If you were listening for the DataForm's EditEnding event, so you could update the database, and return Cancel = true, if something went wrong, sorry. EditEnding never fired. The database wasn't changed, but the grid and the form and the underlying collection were.
So maybe we're supposed to update the database from within the collection or the record objects. Well we can't do it from within the record's EndEdit() method, because from there we have no way of knowing whether we should be doing an insert or a delete.
So maybe we need to be looking at the collection's CurrentChanging event?
Digging into this, it seems that a QueryableCollectionView has a CurrentAddItem and a CurrentEditItem - and if we set e.Cancel = true if either of these is non-null, we can prevent the form from moving to a new record - but this doesn't stop the grid from moving to a new record. And, oddly enough, if you edit a field in the grid, then select a new row, CurrentChanging fires, but CurrentEditItem is null.
So we're back where we started - with a set of demos that show of some really nice glitz, but have enormous holes when it comes to building something that is actually useful.
1 Answer, 1 is accepted
0
Kathy Schmidt
Top achievements
Rank 1
Rank 1
answered on 12 Aug 2015, 03:26 PM
Did you receive any feedback on this post? I am currently trying to understand the issues that you mentioned.