Differences between Me.Undo and DoCmd.RunCommand (acCmdUndo)

[Guest]

Hi,

I have been testing the Undo commands via a button on a form, and I'm
curious as to the differences between these two: Me.Undo and DoCmd.RunCommand
(acCmdUndo).

I've noticed that Me.Undo doesn't undo a change if I save the record (I have
a button on the form for this, using acCmdSaveRecord) after editing it,
whereas acCmdUndo works even after saving the record.

So, for example, if for an existing record, if I change the value in the
city field from "Antigua" to "Jamaica", and hit the "Save" button, and then
hit the Undo button, if the code is Me.Undo, it doesn't do anything, but if
the code is acCmdUndo, it changes "Jamaica" back to "Antigua".

Is there a reason for these two different behaviors? Are there situations
when one is used over the other?

I'm just curious, and if someone can shed more light on this, will
appreciate it.

Thanks.

-Amit

 

[Allen Browne]

Me.Undo cancels the edits in a specific form, so that it is no longer dirty.
Once the form is no longer dirty, no further undo is possible, because it
has reached the desired state.

The RunCommand programmatically simulates the user clicking the Undo item on
the Edit menu. This is a much more generic undo. Access performs it on
whatever object currently has focus. That undo operation might not be
related to a record at all: for example, if the form is open in design view,
it could undo a design change to the form. Some versions of Access provide
multiple undos through the menu, and so the RunCommand is able to step back
through further operations than the simple Me.Undo.

You can use the different behaviours to advantage. If you want to cancel any
edits in a form, then Me.Undo is safe: it will not accidentally undo
previous operations, and it will not operate on the wrong object. The
RunCommand is much more risky - at design time, you have no idea what Access
will be holding in its queue - but it does give you access to multiple undos
in later versions of Access.

 

[Guest]

Thanks, Allen. That was helpful.

-Amit

Me.Undo cancels the edits in a specific form, so that it is no longer dirty.
Once the form is no longer dirty, no further undo is possible, because it
has reached the desired state.

The RunCommand programmatically simulates the user clicking the Undo item on
the Edit menu. This is a much more generic undo. Access performs it on
whatever object currently has focus. That undo operation might not be
related to a record at all: for example, if the form is open in design view,
it could undo a design change to the form. Some versions of Access provide
multiple undos through the menu, and so the RunCommand is able to step back
through further operations than the simple Me.Undo.

You can use the different behaviours to advantage. If you want to cancel any
edits in a form, then Me.Undo is safe: it will not accidentally undo
previous operations, and it will not operate on the wrong object. The
RunCommand is much more risky - at design time, you have no idea what Access
will be holding in its queue - but it does give you access to multiple undos
in later versions of Access.