Custom Dialogs - JOptionPane

Question

Hi Guys,
I was after a quick bit of advice. I've written a small routine which handles the JOptionPane dialog when a user wants to delete some files/folders from within my app. I originally had a "showConfirmDialog" type dialog, but I also needed a "Yes to All" button too (for multiple selections). In essence its a YES_NO_CANCEL_OPTION - with an added "Yes to All" choice. I couldn't find a YES_YESTOALL_NO_CANCEL option in the "optionType" parameter in the Docs.
Heres what I've got...
protected int deleteFileCheck(File theFile) {
String fileOrFolder;
fileOrFolder = theFile.isDirectory() ? "folder" : "file";
Object[] options = {"Yes", "Yes to All", "No", "Cancel"};
return JOptionPane.showOptionDialog(null,theFile.toString()
+ "\n" + "Are you sure you want to delete this "
+ fileOrFolder + "?",
"Delete files from this project",
JOptionPane.DEFAULT_OPTION,
JOptionPane.WARNING_MESSAGE,
null, options, options[0]);
which returns -1 for "close", 0 for "yes", 1 for "yes to all", 3 for "no" and 4 for "cancel". This seems to work okay.
Is this the best way to do this??
I'm just double checking really...
Many thanks in advance.

Answer 1

Thanks for replying. I'll try to address your questions.
- Why restrict the design to having only one instance
of the frame? What purpose or requirement does that
fulfill?The app has a single JFrame that serves as the main window for the application. It implements an MDI desktop. Since the app is capable of handling multiple documents, there's no need for other instances of the main JFrame.
You're still free to invoke another instance of the app, but that will be in its own JVM with its own singleton.
- I think you pointed out your problem without
realizing it - why is the frame being passed around
to a bunch of methods? Who controls the frame? The app has many classes that subclass JDialog. JDialog's constructor expects a reference to the Frame or Dialog that owns it. I could use null here, but it's a personal preference to include it if possible.
The frame controls itself. For example, when the user takes some action that requires adding a new JInternalFrame, the code calls MyMainClass.getMDIDesktop().addInternalFrame() (assuming getMDIDesktop() is left as a static method; if not, the call becomes MyMainClass.getInstance().getMDIDesktop().addInternalFrame()).
- Should the controller of the frame provide
it on demand (accessor) instead of handing it off to
everyone to use for their own purposes? I guess I don't understand how what you're suggesting is substantially different than what I'm proposing. The (singleton) controller of the frame (which happens to be the frame itself) provides a reference (via .getInstance()) to whoever needs it -- rather than passing it explicitly.
- Who's creating all these dialogs such that they
need their own reference to the frame - why isn't it
the same class that controls the frame?The reference is often just to establish parentage, but also to allow various dialogs access to methods to create new internal frames/update existing internal frames/etc.