> I think semi-automatic TableUpdate() attempts in form.Deactivate()
> might not be what users expect and it would get much more
> complicated to tell Gene's buttons or secondary forms whether
> the update attempts have succeeded or failed, and if the latter,
> what to do next.
That's true.
What can you do if a secondary form needs all data be stored on
disk rather than just in memory.
It's of course better you don't need to save everytime you leave a form
just because the data _might_ be needed by the secondary form or re****t.
I'd perhaps rather put buttons with calls to related forms or re****ts
on the data entry form, so it can know when it needs to save. And
if a users runs a form in parallel the user has to live with the active
record(s) of the still open edit form not being available as long
as the user didn't save.
I'm now reimplementing an application and we made the choice to
have save buttons on the forms, while in the previous version that
was an automatic feature of the close button. It's now an extra click,
but the user gains more transparency on what's happening, what's
only in memory and what's really saved, so he doesn't get surprised,
that the data he is modifying or entering right now is not available for
re****ts before he saves.
More general we decided, each button should do a seperate function,
nothing is coupled. save is just save, close is just close and
cancel just cancels.
Closing without saving causes a warning message, but it does no
autosave, you can decide not to close, but then must press save.
The user should have control and not be overruled by default
behaviour, even if it's a good idea to save by edfault, the user might
wanted to cancel and even if that is an extra click everthing
is done with more control on the user's side.
The exception is overruling that behaviour with cancel or save,if an
automatic/administrative shutdown is needed.
Bye, Olaf.
|
