sequence of events

  • Thread starter Thread starter cbnewman
  • Start date Start date
C

cbnewman

What is the sequence of events when a user closes a form window by
pressing on the "X" at the upper right-hand corner of the window?

I find it a little counter-intuitive that any updates that are made to
form controls are propogated back to the table, rather than the
default action being to undo any changes.

Where is the best place to trap this event and prompt the user to
commit or undo the changes to the form? What is some logic that I
might be able to use to see if any changes have actually been made to
the form or if the form is about to make changes to the underlying
record?

--b
 
It is well much the way most database systems have worked for about 20+
years in our industry.

Actually, there is amazing amount of systems in place that do implied saves
for you. For example, take outlook express. When you create a email and
send, in fact the email is first saved to the outbox. You are not prompted
in this case. (after all, it would be silly to be asked to save after it is
clear that the user already hit send.

It is much like car, where you turn
the key, and the up pops a box, asking - do you want to start the car?

And, even in product like outlook, if you create a "note", and close it..it
actually gets saved..and again no prompts....

And, the wildly successful (and easy) to use palm pda's also have implied
saves.

And, just the act of placing, or moving a icon on your desktop also saves
the position of the icon to disk for you (should we annoy the user and
prompt in that case?).

The main difference here is that products like word, or excel are document
orientated..and not data orientated (and, to be fair, products like word
does in fact have a autosave!).

A user working in excel editing one row of data does not think that moving
to the next row should cause a save. However, when you present the data as a
grid from a database..then moving via the cursor does cause a save. The
difference here is one system is a document, and the other is a data
management system.

FoxPro, Dbase, DataEase, Filermaker, Knowledge man, alpha
5 etc all in fact use implied saves. And, they all done so for a about 25
years in the pc industry. So, while *you* might think it counter intuitive,
25 years of products in our industry shows otherwise (I am hard pressed to
find any database product that actually prompts for a save due to record
navigation). Heck even the tools for sql-server also use implied saves.

Once again, if a user is moving to the next record...then I can't imagine
why they would not want to save? (there might be the exception..but then why
torture the rest of the world for these exception).

So, the above is not a big deal..but virtually all database products I used
have implied saves..and just like turning the key on a car..it is the users
actions that dictate what happens. if you going to close a form, then why
would you not want to save? Why is the user closing the form then? If they
want to under their changes...then they go edit->undo. I mean, if you take
1 million people,and have them close a form, 99% of those people will want
the record saved. It makes no sense to torture 99% for the 1% of the time
when the record is NOT wanted to be saved.

You can easily implement a save dialog in a ms-access form. However, if you
are going to use a sub-form, THEN YOU CAN NOT do this!! The reason for this
is that ms-access uses bound forms, and the instant you move the cursor (or
click via the mouse) to a sub-form, the main form record is SAVED to disk.
The reason for this is simple:

You can't add child records to a table without first having saved the
parent record.


So, if your application will not use any sub-forms, then you can implement
a save dialog into your application..but if you going to use sub-forms,
then this whole concept breaks down. The only solution is to make a copy of
the main form data, and a copy of the sub-form data..and let the user edit
that data..and then sent it back to the table (this is messy...but about
only reasonable option you have).

You might have to re-consider your design, and adopt the implied save model.

You could also consider using a different tool. The above long post is not a
right, or wrong on this issue. There are many cases when people do want, and
do need a save button, but you really do want to give this some through.

Do you save when you move to the next record. if the user answers no to the
save, do you stay on the current record, cancel changes, or simply move to
the next record? what is it that the user is trying to do at this point
(answer..move to the next record). If you cancel the changes, but move to
the next record, you get tons of uses wondering why their work is not saved.
You are in for a HUGE surprise if you think accidental changes is a greater
problem then that of users not saving their data...


--
 
it's because my users are not used to using a database-oriented (or
even spreadsheet-oriented) paradigm. I'm trying to mimic functionality
for every other computer application I can think of with regards to

For example:
open a document in the application of your choosing (word,
dreamweaver, power point, adobe, photoshop, etc).
edit that document.
close the window or application without explicitly saving that
document.
the default behavior for 99% of applications is to verify your action
(even Access does this! in design mode for reports and forms,
datasheet view for tables, deleting records by hand from tables, etc).
As a programmer and a computer user for 20+ years myself, i get very
annoyed by this behavior (i.e. the application "second guessing" the
user). But the fact is that most people (especially my users, from
what I have observed) *expect* this behavior and i believe they now
are dependent on it; that is to say that they rely on the fact that
they can inadvertently close a document and if it has been changed
without being saved, they will be prompted to save or discard their
work.

The functionality might be historically different in database
application programming, but it runs counter to the dominant (at least
from my observation) contemporary paradigm in application programming.

As for prompting record saves during record navigation, I never asked
for that. I am only concerned about closing the form prematurely and
what the best way to trap that event is (i.e. differentiate, if
possible, from a close_form button click event). And no, I am not
using subforms (but even in the example you provide, I don't see how
it's not possible because saving the main record to disk and
committing the transaction to the database are two conceptually-
distinct entities.).

--b
 
I am not
using subforms (but even in the example you provide, I don't see how
it's not possible because saving the main record to disk and
committing the transaction to the database are two conceptually-
distinct entities.).
Click to expand...

Because you like presenting a main customer form, and then a "many" lines of
detail for the customer order for example. If you adopt the "save" button
idea, then you users are going to expect the save button to save the whole
form, and including the "many" records on the sub-form.

So, when you click on the invoice details (or tab into he sub form if you
have decent navigation), then you have to save the main form. You are now
able to edit and add "many" sub-form records, and each time you cursor down,
or move to the next sub-form record, you must save the current record. So,
at this point, the main record is saved, and you may have added 4 sub-form
records, and then the user hits the close button you speak of. At this
point, the main record been saved a long time ago, and so have 4 sub-form
records. When the user clicks close, they are expect that save prompt you
talking about. So, you *can* still provide a save prompt, but the conceptual
model you asking for still breaks down (they are not saving the whole screen
as a close..but only the current record of the sub-form could be prompted
for saving).

All I pointing out that if you train and design all your main forms to
prompt the user, this whole concpetial model breaks down if you use a
sub-form. You not going to be albe to un-do those sub-form reocrds, and hte
main reocds was long commited to disk. So, it not that you can't pomropt for
a save, but you going to have to oprt the user when you tab (or click) into
the subform to save the main form, and then for each editng (or even simply
edit + navagation) in those sub-form roecrds, you have to prompt the user.
So, you *can* prompt the user, but hte conicopa model you aksing for does
not work in that case.

And, i not pointing out that what you ask for is somehow wrong, but I just
poting otu that manualla, rpormamogn ernfnece, and vitually everthign you
will read abount ms-access is buuilt on this impled saves concpet. So, even
if we don't like the way it is...it is the way it is!!!

If you want to place a save buttion on your form, you can go:

if me.Dirty = true then
me.Dirty = false
end if

If you want a save prompt for your form, then, then you can place the
follwing code in the forms
before udpate evetn:

If MsgBox("do you want to save?", vbYesNo) <> vbYes Then
Me.Undo
End If


If you want to do it on the close event (barring in mind that if the user
clicked into the sub-form, the record is already saved....and your close
event will not detect that the record is dirty...because it will not be!!!.

If you have a custom save button, then it is easy. However, if the user
closes the application, or the form, then you don't know which is closing
the form (is it the application being closed, or the form). Thus, you can't
really distinguish between the two. And, the un-load event, and the close
event fire well after the record been written to disk. So, unless your using
a custom save button, you can't really provide a save *only* because the
user clicked on the "x" to close the form...
 
Back
Top