Re: ? Savings In-Edit Drafts
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 25 Sep 2008 23:42:28 -0400
See below...
On Thu, 25 Sep 2008 13:27:51 -0400, "Alec S." <@> wrote:
****
Tom Serface wrote (in news:66429597-385B-4EA2-8D74-192945E47AAC@xxxxxxxxxxxxx):
"Alec S." <@> wrote in message
So basically, I'm looking for some advice on implementing a
save-open-documents architecture in a dialog app.
You could also hook on almost any process in the list control (when a
change is made for example) and count the number of entries made then
save periodically in that routine.
?
You could also store just data that has changed (that allows you to reenter
the stuff that was entered since last save or save in small increments (more
often) so that the time lag is not annoying.
That would render the Cancel button pointless since it is autosaving the open
entry. I?m not sure how to address that; I?m thinking that I?ll have to create a
separate area to save currently open entries.
Many apps, if you make a change in the data which is then applied, changes the caption on
the button from "Cancel" to "Close", and once a change is committed, it is not changeable
and cannot be cancelled.
Another technique is to use a transacted database and not commit the transaction until the
OK button does a commit; Cancel will do a rollback. Ultimately, you have to deal with the
fact that you have created a situation where you have said "I want to change the file, but
I don't want to change the file". That cannot be supported unless you implement your own
commit or rollback mechanisms (you can do "eager commit" with rollback, or "lazy commit"
with failure-to-actually-commit, as two possible algorithms, for example)
****
****
That way it wouldn't do the save until they finish an entry.
That?s basically how it is now: they have to finish editing the entry before
saving can work. What happens if they are working on a big entry and the
computer crashes or something? They have to click OK and then save every now and
then (thus making autosave pointless).
Well, there are several possible actions:
(a) you're screwed
(b) the transaction, or partial transaction, is written to a "pending transaction"
file by opening the file, appending the record, and closing the file. When
OK is clicked, the contents of this file are read and committed to the main
file; on Cancel, the file is deleted
(c) you use a transacted database for your data repository
(d) there is a 'save' feature in the dialog that will send a message to the parent
that does the save without having to exit the dialog.
****
****
BTW, I always like Ctrl+S functionality so I can save without having to move
my hands from the keyboard.
Agreed. I just tested it, and apparently I already implemented that. :) Of
course it only works in the main interface for now, that?s why I need a way to
let them save while entries are open. I guess when the edit dialog gets Ctrl-S,
it would have to pass a message back to the main app so that it can save.
See my suggestion (d) above. Note that this does not guarantee the integrity of the data
if the record is not complete, and there is no way to undo the change to the database
unless you implement a rollback mechanism or use a repository with a rollback mechanism.
****
****
Can your users actually work in more than one dialog at a time?
Not at the moment, the edit dialog is still modal. Once I make it modeless, they
will?assuming the dialog isn?t maximized. (I know, I know, it?s becoming a
homemade MDI app.)
I've done this but I didn't need to support rollback.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- Re: ? Savings In-Edit Drafts
- From: Tom Serface
- Re: ? Savings In-Edit Drafts
- Prev by Date: Chopard Happy Sport Diamond Steel Black Ladies Watch 27/8892-23
- Next by Date: Re: Use a DC in a worker thread
- Previous by thread: Re: ? Savings In-Edit Drafts
- Next by thread: a disk file copy function is needed
- Index(es):
Relevant Pages
|
