Save FileDialog in Java strips initial file extension

Question

I'm using java.awt.FileDialog to create a dialog for saving a file. The problem is that when I specify a suggested (default) file name, FileDialog strips its extension. Example:

import java.awt.*;
import java.io.*;

public class SaveFile {
    public static void main(String[] args) {
        FileDialog fileDialog = new FileDialog(new Frame(), "Save", FileDialog.SAVE);
        fileDialog.setFilenameFilter(new FilenameFilter() {
            public boolean accept(File dir, String name) {
                return name.endsWith(".txt");
            }
        });
        fileDialog.setFile("Untitled.txt");
        fileDialog.setVisible(true);
        System.out.println("File: " + fileDialog.getFile());
    }
}

I would expect that when the FileDialog appears, the default file name is "Untitled.txt", but instead it is just "Untitled". When users click Save, I get back a filename without the extension. FileDialog does this on both Windows and OS X.

I don't get it. Why would FileDialog deliberately strip the extension? Is there some logical reason for this? The documentation doesn't discuss it. As a workaround, I could simply add the extension to the string that FileDialog returns, but still, this seems like a bug...

(Note that I cannot use JFileChooser; I need the native AWT FileDialog.)

Solution 1

This doesn't happen for me, on Windows 7, with Sun Java 1.5 and 1.6.

The behaviour I get depends slightly on the setting of the "Hide extensions of known file types" in Windows explorer. If that's on, then the I don't see the extension in the file dialog, as you might expect, but it does return me the full file name.

EDIT: Realise I was wrong about AWT and native widgets -- confusing AWT and Swing.

Solution 2

Here is an example how to save a new file to specified directory and name of file from FileDialog , Strings taken from a vector of Strings.It works for me !

public static void SaveFileTo(Vector<String> myLines) {
        FileOutputStream f = null;
        DataOutputStream h = null;
        FileDialog d = new FileDialog(new JFrame(), "Save", FileDialog.SAVE);
        d.setVisible(true);
        String dir;
        dir = d.getDirectory();
        File oneFile = new File(dir + d.getFile());
        try {
            oneFile.createNewFile();
        } catch (IOException e1) {
            // TODO Auto-generated catch block
            e1.printStackTrace();
        }
        try {
            f = new FileOutputStream(oneFile);
            h = new DataOutputStream(f);
            for (String de : myLines) {
                h.writeBytes(de);               
            }
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }finally {
            try {
                h.close();
                f.close();
            } catch (IOException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }

    }

Solution 3

I've been looking for an answer to this very same problem which appears only on Mac. You either have to live with the ugly JFileChooser (swing, lightweight, not native look) option, or have an if (os is mac) and handle things differently by putting the file extension at the end yourself.

It's a Mac Java AWT bug that will hopefully be fixed at some point.

Comments

[vocaro]

Thank you for the insight. You are indeed correct that the behavior on Windows depends on the "Hide extensions" setting. And you're right, it does return the file name with the extension, even if "Hide extensions" is on and the user does not explicitly add the extension.

[vocaro]

The problem seems to be isolated to the Mac version of Java. The Mac also has a "Hide extensions" setting; however, if that setting is on, the extension is hidden in the dialog text field, but the returned string does NOT include the extension. This is clearly a cross-platform bug, so I'll file a report with Apple. Thanks again for your help.

[Igor]

@vocaro Did you files a report? Any links? How did you solve this issue?

[vocaro]

@Igor I filed one in Feb 2011 at Apple's Bug Reporter site as #9062943. In Jan 2012, they said I should verify the bug using JavaSL10M3503 or later, which I assume means they found and fixed it, though I've not confirmed myself.