Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-1259400

FileDialog.setFile() seems broken on Solaris. Also start working directory...

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      1.1.1
    • CPU:
      generic, sparc
    • OS:
      solaris_2.3, solaris_2.4, solaris_2.5
    • Verification:
      Not verified

      Description

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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              gsaab Georges Saab
              Reporter:
              epelegrisunw Eduardo Pelegrillopart (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: