FileDialog seems to be ignoring setFile() under Solaris.
Also, FileDialog starts on a "/" by default under Solaris.

On the other hand, setFile() seems to do the right thing under win32,
and the default directory is user.dir under Win32, as I would expect it.

I've tried this with the latest JDK1.1's that I could find.

on Win32, java.exe was dated 7/13/96 @ 3:24am
on Solaris, java was dated 7/13/96 @ 5:07am

PS: shouldn't we have unique version strings for all of these builds? I should be
able to say "java -version" and get something I can feed you, without having
to rely on the modify date on the file; JDK1.1E does not help, but just adding
the build date to it would be enough.

I am using the following program to reproduce the problem...

=========== This is Main.java ========

import java.awt.*;

class Main {
    public static void main(String argv[]) {
Frame f = new Frame("Mumble");
Panel p = new Panel();
f.add(p);
p.resize(100,100);
f.setLayout(new GridBagLayout());
f.resize(600, 450);
f.show();

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

The description field as copied from bug report 1261070 follows:

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);
    }
}