I have an Undo button that cancels any changes made to the record. I recently had a user attempt to try to use it to delete the record. Since nothing the record wasn't "dirty", the user got an error that said The command or action 'Undo' isn't available now. Is is possible to test if it is available so that I can set the button's Enabled property to true or false so that the user can't click the button if 'Undo' isn't available?
-
-
Once the record is saved, there's very little you can do without an audit trail of some sort to revert.
What I've done in the past is check for the "dirty" status, if the form/control is dirty then it's reasonable to expect the undo to be available.
Undo Method (v2003) this is still valid for v2007/2010.Last edited by zmbd; Jan 2 '13, 03:53 PM. -
A thought...
I don't know how your record set is setup; however, you might be able to move to the last modified record (set your bookmark in code? ) then ask the user to confirm the record delete before deleting the record.Comment
-
I hadn't thought of testing for the form's "dirty" status.
In thinking about what event(s) to put this test in, I thought of the form's On_Dirty event. I looked it up in MSDN and it says "The Dirty event occurs when the contents of the specified control changes." I assume that as this is a form event and not a control event, the the "specified control" would be the form in this case, correct?
Also, if I'm thinking correctly, I would also need this in the form's On_Current event so that it would check the form's dirty status when the record changes. Although, at the time the record changes, it will save the current record (making Me.Dirty = False) and the new record won't have been changed yet (so that record would still be Me.Dirty = False). So maybe I should just set the Undo button to Enabled = False in the On_Current event and just let the form's On_Dirty event be the one to enable the Undo button. Hmmm.... Thinking out loud :)
I will give this a shot. Thanks Z.Last edited by zmbd; Jan 2 '13, 05:08 PM. Reason: [Z{I Split your follow-up post to this one into a new thread :) }]Comment
-
Don't worry about the help text Seth, Forms have an OnDirty property too, and can capture when the buffer is first dirtied. You would also need to capture OnUndo as well as AfterUpdate events for the form.Comment
-
The AfterUpdate event should be able to replace the OnCurrent event, correct? My thinking is that moving records would trigger the AfterUpdate event first, so just the moving of the record wouldn't require code.
So I'm sitting on a record.
Start changing data (OnDirty triggers setting Me.Undo.Enabled = True)
I click the Undo button (triggers the OnUndo event setting Me.Undo.Enabled = False)
I change more data (OnDirty triggers again: .Enabled = True)
I move to the next record (AfterUpdate triggers setting .Enabled = False)
I make a change (OnDirty triggers)
If I would ever have a Save button, this would trigger the AfterUpdate event I believe and make the proper .Enabled setting.
I believe my logic is complete (thanks to suggestions by NeoPa) and that I have all my bases covered without the OnCurrent event. Does this seem logical?Comment
-
OnCurrent is not, nor ever was, something to include in such logic. The reason, should you be curious, is explained very well in post #4.
Your reasoning in post #6 seems faultless to me, and mirrors my own thinking when I suggested those properties ;-)Comment
-
Okay, Great! Thanks Z for pointing out what I can test for (my original question) and to NeoPa for pointing out where to put it.Comment
-
I've always been happy to tell people where to put it Seth, but you're probably the first to thank me for it :-DOriginally posted by SethComment
Comment