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

[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.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"martin" <no***@nowhere. orgwrote in message
news:45******** **************@ news.kpnplanet. nl...

>
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

[Armen Stein]

On Tue, 13 Feb 2007 10:05:43 +0900, "Allen Browne"
<Al*********@Se eSig.Invalidwro te:

>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?

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Armen Stein" <Ar********@R3m 00v3Th1s.gmail. comwrote in message
news:ed******** *************** *********@4ax.c om...

On Tue, 13 Feb 2007 10:05:43 +0900, "Allen Browne"
<Al*********@Se eSig.Invalidwro te:

>>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

[Armen Stein]

On Wed, 14 Feb 2007 11:17:44 +0900, "Allen Browne"
<Al*********@Se eSig.Invalidwro te:

>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