I know it's not in a DataView, but it is in a DataTable. Anyway - my ObjectView is bound to a datagrid. When the user moves from row to row, I'd like to pop up an annoyer for them to save the row.
The help for DataGrid says "get the event from the underlying datasource" but, of course, in this case that doesn't seem to exist.
Is there another way to know when the bindingmanager's current position is changing, BEFORE it changes? Or is this something that could be added to ObjectViews?
Cheers
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you want to annoy your users to save the data, you might as well handle the ListChanged event and check for ListChangedType.ItemChanged.
I don't know if this will prohibit navigating to the next row, but at least you only get warnings if something really has changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at original request from a slightly different perspective, the reason I wanted the "RowChanging" event was to have a chance to do some validation and user save confirmation stuff prior to moving the row.
Another way of looking at it is to allow the currencymanager position to change (the user requested it, after all) but give them the chance to save, cancel etc.
This being the case, one approach would be to add an event handler to the view which gets called from within the 'if (this.isEdit)' check in the ObjectViewRow EndEdit override.
If the "sender" parameter was the current row and the EventArgs could contain a 'Cancel' option, the handler (where implemented) could set a flag which meant the remainder of the EndEdit function called across to CancelEdit instead.
Worth a try? Or has someone a better idea?
Cheers
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I played with this some more today, and consequently learned a whole lot more about what I actually want to do :-)
When the row changes off a datagrid, EndEdit is called. At the moment, the ObjectViewRow EndEdit handler goes through a loop committing changes and checking for them at the same time.
I'm after changing the sequence somewhat. From:
- EndEdit gets called by the CurrencyManager, ie this is our entry point as far as change is concerned...
- EndEdit writes the changes from temp back into the source row;
- EndEdit cleans up the temp change store.
To something which allows an abort before the data is changed, and which also allows a target specific (eg NHibernate) mechanism to do something with the freshly changed data.
- EndEdit gets called;
- EndEdit determines if anything has been changed. If not, it continue as it works currently. Otherwise, it gets interesting, as follows:
- EndEdit sets up an EventArgs derivative (EditEndingArgs?) with a DesiredAction defaulted to NormalEnd;
- We fire the EditEnding event from the ObjectView, passing the ObjectViewRow as the sender and the EditEndingArgs as the eventArgs parameter. The handler (if registered) gets invoked and can change the DesiredAction in the args to either CancelEnd or EndAndSave;
- Flow returns to the EndEdit method.
- if the arg is still NormalEnd or is EndAndSave, we continue as currently implemented.
- if the arg is CancelEnd, we call CancelEdit and bail from the EndEdit function.
- if the arg is EndAndSave, we fire the RowSave event passing the current ObjectViewRow as the arg and an empty EventArgs parameter. Anyone who traps this event can now go and save it.
Guys, though it seems to work, I reckon it's a bit messy. Any ideas on maybe a better way of allowing these two hooks (one to trap and maybe cancel, maybe save the dirty data row changing thing, one to actually save)?
Or should I create a patch and hand it over to Donald to look at?
Cheers
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This worked beautifully. Even when you change row to add a new record etc, is good.
Except.
If I click on a save button, or do _anything_ which causes an EndEdit (calling CurrencyManager.EndCurrentEdit() for example), I get the same behaviour.
So now when I click on my Save button (which ends the current edit) I get prompted "Would you like to save changes before you lose them?".
AAAAARGH!
So I wanna trap this current row changing event but CurrencyManager gives no hook to do it and by the time it gets to the ObjectView it's too late to work out how we got there and whether to handle it or not.
Back to the drawing board - maybe I need to forget about incorporating it into ObjectViews and extend CurrencyManager instead...
Any alternatives please let me know.
Cheers
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ObjectChanging and ObjectChanged events make sense except for one thing. Objects can get changed without the objectview knowing about it. Unlike a DataTable, you can get a reference to the object and perform and changes you want without the ObjectView knowing. The events would only fire for events going through the designer (probably only when IEditableObject is used).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey guys
I know it's not in a DataView, but it is in a DataTable. Anyway - my ObjectView is bound to a datagrid. When the user moves from row to row, I'd like to pop up an annoyer for them to save the row.
The help for DataGrid says "get the event from the underlying datasource" but, of course, in this case that doesn't seem to exist.
Is there another way to know when the bindingmanager's current position is changing, BEFORE it changes? Or is this something that could be added to ObjectViews?
Cheers
Simon
If you want to annoy your users to save the data, you might as well handle the ListChanged event and check for ListChangedType.ItemChanged.
I don't know if this will prohibit navigating to the next row, but at least you only get warnings if something really has changed.
I'll look into that event. I DO want to have all the advantages of DataTables, if possible.
It's probably not the next thing I'll do though, so in the mean time try looking at the BindingManger's events..
this.BindingContext[myObjectView].SomeEvent += ...
Hi
Looking at original request from a slightly different perspective, the reason I wanted the "RowChanging" event was to have a chance to do some validation and user save confirmation stuff prior to moving the row.
Another way of looking at it is to allow the currencymanager position to change (the user requested it, after all) but give them the chance to save, cancel etc.
This being the case, one approach would be to add an event handler to the view which gets called from within the 'if (this.isEdit)' check in the ObjectViewRow EndEdit override.
If the "sender" parameter was the current row and the EventArgs could contain a 'Cancel' option, the handler (where implemented) could set a flag which meant the remainder of the EndEdit function called across to CancelEdit instead.
Worth a try? Or has someone a better idea?
Cheers
Simon
Hi again
I played with this some more today, and consequently learned a whole lot more about what I actually want to do :-)
When the row changes off a datagrid, EndEdit is called. At the moment, the ObjectViewRow EndEdit handler goes through a loop committing changes and checking for them at the same time.
I'm after changing the sequence somewhat. From:
- EndEdit gets called by the CurrencyManager, ie this is our entry point as far as change is concerned...
- EndEdit writes the changes from temp back into the source row;
- EndEdit cleans up the temp change store.
To something which allows an abort before the data is changed, and which also allows a target specific (eg NHibernate) mechanism to do something with the freshly changed data.
- EndEdit gets called;
- EndEdit determines if anything has been changed. If not, it continue as it works currently. Otherwise, it gets interesting, as follows:
- EndEdit sets up an EventArgs derivative (EditEndingArgs?) with a DesiredAction defaulted to NormalEnd;
- We fire the EditEnding event from the ObjectView, passing the ObjectViewRow as the sender and the EditEndingArgs as the eventArgs parameter. The handler (if registered) gets invoked and can change the DesiredAction in the args to either CancelEnd or EndAndSave;
- Flow returns to the EndEdit method.
- if the arg is still NormalEnd or is EndAndSave, we continue as currently implemented.
- if the arg is CancelEnd, we call CancelEdit and bail from the EndEdit function.
- if the arg is EndAndSave, we fire the RowSave event passing the current ObjectViewRow as the arg and an empty EventArgs parameter. Anyone who traps this event can now go and save it.
Guys, though it seems to work, I reckon it's a bit messy. Any ideas on maybe a better way of allowing these two hooks (one to trap and maybe cancel, maybe save the dirty data row changing thing, one to actually save)?
Or should I create a patch and hand it over to Donald to look at?
Cheers
Simon
<what's the smiley for egg on my face?>
This worked beautifully. Even when you change row to add a new record etc, is good.
Except.
If I click on a save button, or do _anything_ which causes an EndEdit (calling CurrencyManager.EndCurrentEdit() for example), I get the same behaviour.
So now when I click on my Save button (which ends the current edit) I get prompted "Would you like to save changes before you lose them?".
AAAAARGH!
So I wanna trap this current row changing event but CurrencyManager gives no hook to do it and by the time it gets to the ObjectView it's too late to work out how we got there and whether to handle it or not.
Back to the drawing board - maybe I need to forget about incorporating it into ObjectViews and extend CurrencyManager instead...
Any alternatives please let me know.
Cheers
Simon
Wow, you seem to have put a lot of effort in this. I'm afraid I don't have a simple solution either.
For a quick solution I would use the PositionChanged event in combination with a variable that remembers the previous position.
ObjectChanging and ObjectChanged events make sense except for one thing. Objects can get changed without the objectview knowing about it. Unlike a DataTable, you can get a reference to the object and perform and changes you want without the ObjectView knowing. The events would only fire for events going through the designer (probably only when IEditableObject is used).