5

I'm writing what boils down to a document editor. When the application is closing, I need to prompt the user to save changes. This is easy enough. My question is when is it appropriate to not prompt the user, and instead simply discard unsaved data and close.

In the FormClosing event, the CloseReason enum includes:

  • None
  • WindowsShutDown
  • MdiFormClosing
  • UserClosing
  • TaskManagerClosing
  • FormOwnerClosing
  • ApplicationExitCall

I figure that WindowsShutDown and TaskManagerClosing should not cause a "save changes?" prompt to appear, to prevent the app from hanging with that prompt showing.

Is this standard practice, or should I be doing something else here?

For clarity, here's the code:

protected override void OnFormClosing(FormClosingEventArgs e)
{
    base.OnFormClosing(e);

    if (!(e.CloseReason == CloseReason.WindowsShutDown || e.CloseReason == CloseReason.TaskManagerClosing)
            && this.ChangesPending())
    {
        switch (MessageBox.Show(this, "Save changes?", "Save Changes", MessageBoxButtons.YesNoCancel))
        {
            case DialogResult.Yes:
                this.Save();
                break;
            case DialogResult.No:
                // Do nothing
                break;
            case DialogResult.Cancel:
                e.Cancel = true;
                break;
        }
    }
}
Jon B
  • 51,025
  • 31
  • 133
  • 161

5 Answers5

3

I think TaskManagerClosing should be the only reason that does not prompt, if any. Personally, I would want to be prompted in the event of WindowsShutDown. If I'm shutting down Windows with an unsaved document somewhere, it means I've forgotten about it.

recursive
  • 83,943
  • 34
  • 151
  • 241
3

I'd definitly also show the "Do you want to save" dialog on WindowsShutDown (the application might e.g. have been in the background for some time and the user forgot about it, or he might have clicked on "Restart" after a service pack was installed without thinking twice etc.).

As for TaskManagerClosing, I'd not show the dialog in this case.

ISW
  • 11,110
  • 3
  • 25
  • 27
0

I personally prefer to just close the program when the user selects close, if there are any unsaved documents at close time I prefer to keep backup copies of those files and inform the user that there are unsaved documents when they next open the application.

I do this for a couple of reasons, number one I like my applications to close when I tell them to close, and number two by keeping a temporary copy of the file that I update with all the changes as the user works on it I safeguard against unexpected crashes and closes of my applications.

So with this technique you don't need to worry about ow the application has been closed.

CalvinR
  • 744
  • 1
  • 5
  • 11
  • That runs very much counter to how most apps work - I think the user expects to be prompted when the app closes normally. – Jon B Jan 20 '09 at 20:24
  • I like the idea, but Jon B is right... this greatly violates the principle of least surprise. – rmeador Jan 20 '09 at 20:31
  • I think you mean to say this run counter to how Microsoft Office works. Vim works in this manner and I must say I'm personally a big fan of the feature, it's saved my butt more then once. So I've started implementing it in all of my apps that I build. – CalvinR Jan 20 '09 at 20:32
  • I don't know I think that expecting an application to quit when the user closes the application is the least surprising result in this sitaution. – CalvinR Jan 20 '09 at 20:34
  • CalvinR - I'm not dismissing the idea of an autosave, I just think users have come to expect a "Save changes?" prompt when closing (assuming there are pending changes). In my case, I think my users are more familiar with Office than Vim. – Jon B Jan 20 '09 at 21:04
  • I don't know how you mean Vim has this behavior... if you do :q, it will prompt you to save (unless you do :q!). If it's gvim and you click the X, it will prompt you graphically. If you use the kill command to send it a signal, then it will close silently, which is analagous to TaskManagerClosing. – rmeador Jan 20 '09 at 21:30
0

Really the CloseReason is a moot point, isn't it? The fact that your form is going away is what you're trying to catch.

Now you need to know if your application has already handled the "save" event. If so, the form can go away. You've saved your document. But if not, you may want to prompt the user.

If you can validate the data quickly (i.e. do a string compare or hash compare on the document compared to the data in the file) then you'll know if the user has saved the form data.

Otherwise, if there are alot of fields, and checking each one is resource-prohibitive, then put a "isDirty" flag on your form. Let the Save() method set the isDirty to false, and every other field change sets it to true.

Then, in formClosing, all you need is :

protected override void OnFormClosing(FormClosingEventArgs e)
{
    if (isDirty) 
    {
        DialogResult R = MessageBox.Show(this, "Save changes?", "Save Changes", 
                MessageBoxButtons.YesNoCancel);

        if (R == DialogResult.Yes)
        {
            this.Save();
        } else if (R == DialogResult.Cancel)
        {
            e.Cancel = true;
        }
    }
}

Jerry
  • 4,507
  • 9
  • 50
  • 79
0

I'd think even TaskManagerClosing could use a prompt to save. If your app is responding normally, closing it through the task manager should be no different from any other way of closing it. If it's hung, it doesn't matter what your onClose handler does - it'll never get there.

I agree with @Jerry, in that it's more important to avoid prompting to save if the data hasn't changed since the last save. I usually use a simple 'changed' flag, which gets set on any edit action, and cleared on saves and loads.

AShelly
  • 34,686
  • 15
  • 91
  • 152