These are arguably two differnt bugs but they seem close enough that they are
probably best filed as a single bug.

Run the program below using JDK1.1 under Solaris/SPARC [and also JDK1.0.2]. It will
pop-up a FileDialog. Notice that "12.foo" is not in the selection field; that is the first
bug.

Don't touch anything, now click on "Save", notice that the filename returned is
a null string; Tom Ball suggests that that is also a bug; excerpt from mail from Tom
follows below. I'm not sure whether there may not be a situation where getFile()
should return null [what should it return if the selected field is empty?, raise an
exception?], but in any case in this situation it should return something like "12.foo"!

Tom Ball says:
| Eduardo says:
| > If I then click on save (touch nothing), fn is "null", and dn is "/tmp".
|
| This is proof that Motif is brain-damaged (are you listening, Amy? :-). What
| possible use is it to return null from a show, unless the user explicitly
| cancelled the dialog? The Motif peer will need to wrap this in a loop to
| reshow until the dialog is either cancelled or given a filename. Most AWT
| developers will assume this behavior and won't code it themselves. If there
| are any doubts, we'll ask Annette (but I'm confident she'll agree with me).


===================

iimport java.awt.*;

class Main {
    public static void main(String argv[]) {
Frame f = new Frame("Mumble");
Panel p = new Panel();
f.add(p);

f.setLayout(new GridBagLayout());
f.resize(600, 450);
f.show();

FileDialog d = new FileDialog(f, "Something", FileDialog.SAVE);
d.setDirectory("/tmp");
d.setFile("12.foo");
d.show();
String fn = d.getFile();
String dn = d.getDirectory();
System.err.println("Got a filename of "+fn+" and a directory of "+dn);
    }
}