You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
One of the more common tasks on a computer is to undo something you just did by mistake. At least, it's one of my more common tasks. CTRL+Z is my friend.
But not everyone uses keyboard shortcuts - that's why there's an Undo button in the Microsoft Office user interface. Trouble is, sometimes folks just don't see it. Moreover, in Access it's possible that they can't use the toolbar because they are working on a modal form. Fortunately, you can create an "undo" button for any form in Access. And in most cases, you can control what happens when the Undo command is invoked - for example, ask for confirmation before undoing the current record on a huge data entry form.
There are a couple of ways to make an "undo" button, but they all start the same way: add a command button control to your object, and give it an obvious label. Then, add some code to the button's Click event.
One way is using the DoCmd object's RunCommand method:
Private Sub btnUndo_Click()
This code has the same effect as pressing CTRL+Z or clicking the Microsoft Office Undo button. Thanks to your big, obvious button, undoing has never been easier.
Another way is to use the form's Undo method:
When you use the Undo method, you always trigger an Undo event, giving you another opportunity to control the flow of your UI. For example, you might add a confirmation message to the Undo event for a form that has a lot of data controls, as a safeguard for data entry. (VBA gurus - can you think of any circumstances where the DoCmd.RunCommand method of "undo" would not trigger the Undo event? What would be some of the merits and drawbacks of these two "undo" methods?)
NOTE: If you're working on the design of a web form, you need to use macros instead of VBA. To create an "undo" button for a web form, embed an UndoRecord macro action in the button's On Click event.
The Undo method can be attached to an event for a form or a control. You can apply the Undo method to a form, and to the following controls:
To apply the Undo method to a form, use this code:
To apply the Undo method to a control, use the following code (replace <NameOfControl> with the name of the control):
The Undo method offers an alternate way to make "undo" command buttons on forms, instead of using the DoCmd method. For example, if you want to put a button on a modal form so there's an obvious way to undo data changes, the button's OnClick event procedure might look like this:
If the Undo method is applied to a form, all changes to the current record are discarded. If the Undo method is applied to a control, only the control itself is affected.
Every form has an Undo event, as do the following controls:
The Undo event occurs whenever the user clicks the Undo button, presses the ESC key, or performs an action that calls the Undo method of the object. Note that a control must have focus before this will work.
The Undo event for controls occurs whenever the user returns a control to its original state (while the control has focus) by clicking the Undo Field/Record button on the command bar, clicking the Undo button, pressing the ESC key, or calling the Undo method of the specified control. Notably, the event does not occur if the user clicks the Undo Typing button on the command bar.
Can you think of some good examples of using the Undo method and the Undo event? How about best practices for using them? Please do share.
DoCmd.RunCommand produces the error "Argument not optional". Perhaps iit should read
Typos are so easy ....
Thanks Dave. That was in the post originally, but there were apparently some formatting issues with the post that someone else went in and fixed. The argument got lopped off with part of a <span> tag. I've added it back.
Good catch! :)
What versions of Access does this work in?
Great question Ramona! This code works in Access 2003, 2007, and 2010.
The RunCommand method of the DoCmd object was introduced in Access 2003. (It replaced the DoMenuItem method.)
The Undo event was introduced in Access 2002.
The Undo method was available in earlier versions, at least as far back as Access 97.
" (VBA gurus - can you think of any circumstances where the DoCmd.RunCommand method of "undo" would not trigger the Undo event? What would be some of the merits and drawbacks of these two "undo" methods?) "
If you use this:
... and your Form is not currently Dirty, you will receive an Error 2046 "The command or action isn't available now."
Using Me.Undo does not generate the error in this case, it's just ignored. Myself however, I would have an Undo button grayed out unless the Form was Dirty. But nonetheless, that is one difference.
Also, I suspect it is similar to DoCmd.RunCommand acCmdSaveRecord ... wherein sometimes this fails (same message as above) for **no apparent reason** (even if a record is Dirty), whereas Me.Dirty = False will always Save a record ... if, the record is Dirty. If not, again, no error occurs.
And finally, Me.Undo is just a whole lot faster to type ... and with Intellisense, all you have to type is Me + Dot + U
The article erroneously identifies when DoCmd.RunCommand was introduced -- it actually happened with the switch to VBA from Access Basic in Access 95. I don't have A95 to test, but it certainly exists in A97 (which I tested). That was not the kind of feature that was changed between A95 and A97, so I'm pretty certain it was A95 where it was first implemented. Certainly it's been around MUCH longer than A2003, as the article asserts..
@Joe: Great info, thanks for improving the post!
@David: Thanks for the catch about when DoCmd.RunCommand was introduced. I don't have unsupported versions of Access to test things with, and I got that wrong in my comment replying to Ramona (the article didn't mention when this code was introduced). I based that part of my reply on the MSDN page for the Access 2003 RunCommand method, which says "The RunCommand method replaces the DoMenuItem method of the DoCmd object." I mistakenly took that to mean the RunCommand method was introduced at that time, and consequently stopped searching for earlier implementations - it's good to know it works all the way back to Access 97!
@Steven. You are welcome. Off topic ... My 'Settings' indicate I should be receiving Notifys such as the subsequent posts to the post I made. This is not happening. Any clue why?
Now ... from the A2003 Help File - DoMenuItem Method:
"Note In Microsoft Access *97*, the DoMenuItem method was replaced by the RunCommand method. The DoMenuItem method is included in this version of Microsoft Access only for compatibility with previous versions. When you run existing Visual Basic code containing a DoMenuItem method, Microsoft Access will display the appropriate menu or toolbar command for Microsoft Access 2000. However, unlike the DoMenuItem action in a macro, a DoMenuItem method in Visual Basic code isn't converted to a RunCommand method when you convert a database created in a previous version of Microsoft Access."
So ... I would say that "The article erroneously identifies when DoCmd.RunCommand was introduced -- it actually happened with the switch to VBA from Access Basic in Access 95."
... is incorrect ... according to the Help file ... 97 not 95.