I am new to the UltraWebGrid and find it generally very nice to work with. However, in planning how to use it in our business, I am left hanging on one issue. Using a SQLDataSource and by just setting a couple of properties, the grid works great, and every time an edit is made and the user changes grid rows, it silently posts the edit to the database. The good news is that this goes 90% of the way of insuring that edits are committed to the db without the user having to click a save button. But I am looking for how to handle situations where a user edits his/her final record and then closes the form without having selected another row.
Infragistics support informed me that this is the way the webgrid is supposed to work and that I have to teach users to always change rows after making a change. But in terms of customer experience, this seems to beg frustration among users who did not listen or simply forgot (either to change rows or to click a save button) and so their final edits were lost.
So is there a way (hopefully with a simple example) on how to use the BeforeUnload event to (a) determine if there is a lingering edit that was not updated to the database (which should be limited to the last/current row), and (b) how to force that last/current row to be updated if changes are pending?
Thanks for any ideas.
I agree. Customers don't take well to having to be trained.
I'd put a "Save" button on you form. Experienced web users are used to that.
(Actually, experienced web users will know you shouldn't just leave a page without saving, and won't be expecting your grid to auto-save anything.)
That's the best solution I can think of.
However, would putting the "Save" button on the form make them assume the form isn't being saved until they click the button? If it were my form (and I certainly don't understand all your needs), I would add the button and then not save until the button is clicked.
Good luck!
I would use the batch update event handlers to do all the saving at once. This will eliminate the once-per-row postbacks, and it is really very simple to implement.
Define your UpdateRowBatch and DeleteRowBatch handlers, and all your Save button has to do is trigger a postback. The two event handlers need to do pretty much what (I'm assuming) your current UpdateRow and DeleteRow do, and UpdateRowBatch needs to differentiate between inserts and updates.