private JFileChooser chooser;
and I added a line of code in the constructor to construct it:
chooser = new JFileChooser();
Even though we're going to use this object for both input files and output
files, we can use a single object because it knows about both kinds of dialogs.
Then we made changes to the action code for the SaveAction object. It used to
look like this:
public void actionPerformed(ActionEvent e) {
try {
FileOutputStream fos = new FileOutputStream("clicker.dat");
ObjectOutputStream output = new ObjectOutputStream(fos);
output.writeObject(model);
} catch (IOException error) {
throw new RuntimeException(error.toString());
}
...
}
Instead of using a hard-coded file name, we told the chooser to put up a dialog
and request a file name that we retrieved in setting up our input stream:
public void actionPerformed(ActionEvent e) {
chooser.showSaveDialog(frame);
try {
FileOutputStream fos =
new FileOutputStream(chooser.getSelectedFile());
ObjectOutputStream output = new ObjectOutputStream(fos);
output.writeObject(model);
} catch (IOException error) {
throw new RuntimeException(error.toString());
}
...
}
Dialog boxes are modal,
which means that they behave in a different way than other components. In
effect, they demand an immediate answer from the user before anything else
happens. They are somewhat like the GUI equivalent of the console window that
forces the user to interact in a specific way. We're used to this kind of
modal interaction for actions like opening or creating files.We were able to supply a default file name for the dialog:
public void actionPerformed(ActionEvent e) {
chooser.setSelectedFile(new File("clicker.dat"));
chooser.showSaveDialog(frame);
try {
...
}
I tried issuing the command that Horstmann mentions in Core Java as the
command to set the default directory to the current directory:
public void actionPerformed(ActionEvent e) {
chooser.setSelectedFile(new File("clicker.dat"));
chooser.setCurrentDirectory(new File("."));
chooser.showSaveDialog(frame);
try {
...
}
Unfortunately, this doesn't do what it should on a Macintosh. Instead of using
the current directory of the program, it defaults to the root directory of the
machine. I think this is a bug in the Mac Java support.It's important to understand that a real application should have more sophisticated interactions than this. The user might cancel the file dialog, in which case you shouldn't proceed with the operation. The call on showSaveDialog returns a value that indicates whether the user canceled or went through with the action. The program should check this value to make sure that the user wants to go through with the operation, as in:
public void actionPerformed(ActionEvent e) {
chooser.setSelectedFile(new File("clicker.dat"));
int result = chooser.showSaveDialog(frame);
if (result != JFileChooser.APPROVE_OPTION)
return;
try {
...
}
We made similar changes to the restore action using a call on
showOpenDialog. The final version of the class is available as handout #24
from the class web page.I briefly reminded people of the SwingSet2 demo program from the jfc folder. It includes a demo of various kinds of dialog boxes that you can construct (it's the 8th demo in the sequence). Using a JOptionPane, you can construct all sorts of user dialogs. There are several standard dialogs that are defined for you and you can use all of the various user interface elements we've explored like text fields, sliders, buttons, etc., to build a custom dialog. This is explained in detail in Core Java. Starting on page 455, there is an extensive discussion of how to use JOptionPane to make custom dialogs. Starting on page 475, there is discussion of file choosers.
We spent the remainder of class discussing a detailed layout problem that is available as handout #22 from the class web page. The solution we came up with is available as handout #23.