Story:
A user has a new, never-saved document open in DrJava. He attempts to Quit and is prompted whether he wants to save the file. He clicks the "Yes" button, and a "Save As..." dialog is displayed. He decides to cancel the dialog, perhaps because he cannot remember the name of the class and wants to find it in the document. Rather than cancelling the Quit process and returning him to DrJava, this instead cancels only the save dialog. DrJava quits, taking his open, unsaved document with it. The user commences cursing DrJava and its developers for causing him to lose data. . . .
Logged In: YES
user_id=429731
Are you sure about this? DrJava behaves correctly for me on
Linux JDK 1.4.1 and OS X JDK 1.3.1. Where were you testing it?
Logged In: YES
user_id=429731
Oh, wait-- nevermind. You have to say Yes to "Save
changes", and then cancel in the file chooser itself. Yep,
it's a bug.
Logged In: YES
user_id=429731
This is actually one level deeper, in the close
functionality. If you have a modified, unsaved document
that you try to close, then say that you do want to save it
but cancel in the file chooser, it closes the document
anyway. Looks like it turns out to be a flaw in the logic
of canAbandonFile() in the document.
Logged In: YES
user_id=429731
Turns out the save() and saveAs() methods needed to return a
boolean to indicate whether the file selector actually
returned a file (or whether an OperationCancelledException
was thrown). I have that working-- I'll write a test for it
and commit it after 312 today.
Logged In: YES
user_id=429731
This is fixed in the drjava-20030210-2142 commit.