cancel button

[martin]

Hello,

Is there a way to make a kind of "cancel" button on a form?

Suppose you accidently changed or overwrote some data in a form, then I'd
like to leave this form at once and cancel any change made in this form.
Hopefully someone has a clue for me.

thanks a lot!

best regards,

martin

 

[Guest]

Hi Martin,

Sure, as long as you have not commited the changes, you can use code similar
to this to undo your changes:

Option Compare Database
Option Explicit

Private Sub cmdUndo_Click()
On Error GoTo ProcError

Dim lngResponse As Long

If Me.Dirty = True Then
lngResponse = MsgBox("Are you sure you want to undo all changes?", _
vbQuestion + vbOKCancel, "Confirmation Required...")
If lngResponse = vbOK Then
Me.Undo
End If
Else
MsgBox "There are no changes to undo.", _
vbInformation, "No current edits were made..."
End If

ExitProc:
Exit Sub
ProcError:
MsgBox "Error " & Err.Number & ": " & Err.Description, _
vbCritical, "Error in cmdUndo_Click event procedure ..."
Err.Clear
Resume ExitProc
End Sub



Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[martin]

Thank you very much Tom!
this works...
But only for the main-form. Now, there is a sub-form nested in the
main-form, and when I change something on the nested form, the cancel-code
will not work.
Is this easy to apply the cancelbutton (which is placed on the mainform) on
the nested form as well??

best regards,
martin

 

[Guest]

Hi Martin,

You will need to add a second command button to the subform, with a similar
click event procedure. When you change focus between a form and a subform, or
from a subform back to it's parent form, Access will automatically commit
(save) any dirty record. At that point, it would be too late to try to undo
changes to a record in a subform from a command button on the main form.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[Allen Browne]

The question is whether Access has already written the record to the table
or not. You can determine that very easily if you show the Record Selector
(left of form.) If there are uncommitted edits in progress, the icon in the
Record Selector will be a little pencil icon until the record is saved.

If the changes have not been saved, it's just a matter of pressing the Esc
key twice: once to undo the current field, and the second to undo other
changes to the record. If you want to do this with an undo button, use:
If Me.Dirty Then Me.Undo

If the changes have been saved, some versions of Access in some situations
will still undo the change by choosing Undo on the Edit menu. Personally, I
find this behavior really annoying, because it is inconsistent and because
it's very hard to track what actually got changed if you are trying to track
changes through events. I can't really encourage you to do this, but you
could simulate it with:
RunCommand acCmdUndo

But there's a more basic problem with placing an Undo button on a form. Say
you are part-way through entering a date and change your mind, so you click
the Cancel button. At this point, Access handles the events for the text box
you are in *before* it allows the focus to move to the command button. Since
the date is not valid - perhaps you had got as far as 2/9/ - it complains
that's not valid, and won't let you out of the box. So you backspace the
characters out. If this date is required, it still won't let you out of the
box. You can't get to the Cancel button until you enter something valid.

As you can see, a Cancel button on the form is not a good idea. Use the
Cancel button in the toolbar instead, or teach your users to use the <Esc>
key instead.

 

[Armen Stein]

The question is whether Access has already written the record to the table
or not. You can determine that very easily if you show the Record Selector
(left of form.) If there are uncommitted edits in progress, the icon in the
Record Selector will be a little pencil icon until the record is saved.
------------------

As you can see, a Cancel button on the form is not a good idea. Use the
Cancel button in the toolbar instead, or teach your users to use the <Esc>
key instead.

I agree, Allen. And I'll take it a step further, although it is more
complex: load local work tables with all the master & child records
to be edited, bind the form to the work tables, then use OK & Cancel
to control whether they are all committed back to the main tables.
This is the only way I know of to provide a reliable overall Undo
feature.

It's easier to teach users to be careful, and also how to use the Esc
key.


Armen Stein
Microsoft Access MVP
www.JStreetTech.com

 

[Allen Browne]

Yes, that works, Armen.

I presume you have a split database where everyone has their own local front
end, so their edits don't interfere. But if you copy the records locally and
only write them back later when the Comit button is clicked, how do you
avoid different users from overwriting each others edits?

 

[Armen Stein]

Yes, that works, Armen.

I presume you have a split database where everyone has their own local front
end, so their edits don't interfere. But if you copy the records locally and
only write them back later when the Comit button is clicked, how do you
avoid different users from overwriting each others edits?

Hi Allen,

We typically use a separate "work" mdb, also stored locally in the
same folder as the front-end application. This avoids bloating the
application, and we often have code that automatically compacts the
work mdb whenever the application opens.

To mitigate the hassle of linking yet another MDB, we built
standardized relinking code that can automatically and silently relink
to an MDB if it is found in the same folder as the application.
Otherwise, it prompts. This allows us to have auto-linking for local
mdbs, but prompted linking for back-end mdbs on a server.

Regarding committing the records - you're right, it can be an issue.
We've found that either:

a) Last edit wins, and we have to educate the user about that. We
usually find that it would be extremely rare for two users to be
editing the same records in a real world situation.

b) Some kind of "edits in progress" flag can be set at the master
record level when the work tables are loaded up for editing. Of
course, an override capability would also be needed, adding to the
complexity.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com