Me said:
After changing a record when user
tries to goto either the next record or previous record
or close the form, I ask "Do you want to Save changes?"
If No, then I have Me.Undo in the code.
My question is where should the control goto after
user chooses No? Should it remain on the same record
or it should goto the next record or close the form?
Well, where do you want it to go? I mean, if a user is tying to navigate to
another record, then likely they want to go to that record, and 9 hundred
and 99 times out of 1000 they also want the current record to be saved. I
guess it is sad that you bother and torture your uses for the 9 hundred and
99 time that they want the record to be saved. I would think it be better to
teach the users to look at the record select bar to see if they modified the
record, and then teach them abut the edit->undo.
Great software is software that is designed to do what the user wants to do
MOST of the time.
When you put a key in the car, and turn it..the car does not pop up a dialog
box stating:
do you want to start the car?
The fact of turning the key in the car means the user wants to start the
car. The fact of a user navigating to a new record 9999 our of 10,000 means
that they want to save the current record, and move to the next one. Sure,
there is the exception to this rule..but to torture your users with a save
prompt for the next 10 years because 1 out of 10,000 does not want to save
when they move.
Anyway, I suppose there situations where you do want a save prompt (and, I
will leave this issue up to you). Since you do have some code that prompts
the user, you just need to ensure the code is in the forms before update
event, you can use:
If MsgBox("Do you want to save ?", vbQuestion + vbYesNo) <> vbYes Then
Me.Undo
End If
If you place the above code that makes your save prompt in the before update
event of the form, then record navigation, or closing the form etc will
function as normal.
So, if the user navigates to the previous record, and gets the above save
prompt, they can answer yes, or no....but the navigation will STILL
continue. As I mentioned, why would a user hit the navigation button if they
don't want to move?
It is not clear if you are asking how to do this, or are asking what should
happen? As I mention, if the user hits the navigation to move,t hen why
torture them and not allow them to move?
I guess the issue here is that want to understand that a great car that is
fun to drive responses to what YOU WANT to do. Every time you put something
between you, and what you want to do...you frustrate the user. A great car
is great because you turn the steering wheel, and then the car moves.
Great software (and think about software that you love) is software that
also responds to the wishes of the user, and does not nag them with a bunch
of prompts.
Remember, it is the little things that frustrate a user. You ever get a
shopping cart in the store with a bad wheel? It is minor, but that
frustration can build up since when you try and turn the shopping cart..it
does not respond well. That stupid minor little shopping cart wheel can RUIN
your whole experience for that shopping trip. So, the essence of good
products, be they physical, or software is that you don't nag the user..and
make things a free as possible to move around.
And, for those that make mistakes, you have to teach them about the
edit-undo feature. No need to torture 99.999% of users all the time just
because 1 out of a 1000 makes a mistake.
Anyway, the above code should work for you in the cases were you do want the
save prompt. Also, do be aware that if you decode to use sub-forms (what of
the greatest features in ms-access), then users will get prompted to save
the main record when they click on any field in the sub-form, as ms-access
needs to save the main (parent) record before any child records can be
added.
And, if you are looking for some reading on user interface tips, then you
might enjoy reading the fowling on line book about UI stuff:
User Interface Design for Programmers
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html