recovered in case something goes wrong. You know, like with Office products
start it up again it sometimes allows you to pick up where you left off.
Tom Serface wrote (in
news:66429597-385B-4EA2-8D74-192945E47AAC@microsoft.com):
"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.
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).
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.
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.)
--
Alec S.
news/alec->synetech/cjb/net