JDK-4031440 : FileDialog doesn't call FilenameFilter.accept()
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version:
    1.0,1.0.1,3.1,1.0.2,1.1,1.1.1,1.1.2,1.1.3,1.1.4,1.1.6,1.1.7,1.2.0,1.2.2,1.3.0 1.0,1.0.1,3.1,1.0.2,1.1,1.1.1,1.1.2,1.1.3,1.1.4,1.1.6,1.1.7,1.2.0,1.2.2,1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS:
    generic,solaris_2.3,solaris_2.4,solaris_2.5,solaris_2.5.1,solaris_7,windows_95,windows_nt generic,solaris_2.3,solaris_2.4,solaris_2.5,solaris_2.5.1,solaris_7,windows_95,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1997-02-11
  • Updated: 2012-10-11
  • Resolved: 2000-02-29
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  

Name: mc57594			Date: 02/10/97

Windows NT 4.0, Service Pack 2
Pentium 120

Add a System.out.println to the accept method of Main.java
Compile the example (from Java Class examples (from 1.0.2, in which the bug also manifests itself)).
Run using java Main
Put any filter in you wish, the accept method is never called, and the list is
not filtered. 

Code for Main.java follows:

import java.awt.*;
import java.io.*;
class Main extends Frame implements FilenameFilter {
    FileDialog fd;
    TextField tfDirectory = new TextField();
    TextField tfFile = new TextField();
    TextField tfFilter = new TextField();

    Main() {
        super("FileDialog Example");
        add("West", new Button("Load"));
        add("East", new Button("Save"));

        Panel p = new Panel();
        p.setLayout(new GridBagLayout());
        addRow(p, new Label("directory:", Label.RIGHT), tfDirectory);
        addRow(p, new Label("file:", Label.RIGHT), tfFile);
        addRow(p, new Label("filter:", Label.RIGHT), tfFilter);

        add("South", p);

    // Adds a row in a gridbag layout where the c2 is stretchy
    // and c1 is not.
    void addRow(Container cont, Component c1, Component c2) {
        GridBagLayout gbl = (GridBagLayout)cont.getLayout();
        GridBagConstraints c = new GridBagConstraints();
        Component comp;

        c.fill = GridBagConstraints.BOTH;
        gbl.setConstraints(c1, c);

        c.gridwidth = GridBagConstraints.REMAINDER;
        c.weightx = 1.0;
        gbl.setConstraints(c2, c);

    public boolean accept(File dir, String name) {
		System.out.println("File "+dir+" String "+name);
        if (fd.getMode() == FileDialog.LOAD) {
            return name.lastIndexOf(tfFilter.getText()) > 0;
        return true;

    public boolean action(Event evt, Object what) {
        boolean load = "Load".equals(what);

        if (load || "Save".equals(what)) {
            fd = new FileDialog(this, null,
                load ? FileDialog.LOAD : FileDialog.SAVE);
            // Filter must be the same
            if (fd.getFilenameFilter() != this) {
                throw new RuntimeException("Internal error");
            return true;
        return false;

    static public void main(String[] args) {
        new Main();


company  -  Object Guild, Inc.  , email  -  ###@###.###

WORK AROUND Name: mc57594 Date: 02/10/97 Unknown ======================================================================

PUBLIC COMMENTS FileDialog doesn't call FilenameFilter.accept().

EVALUATION There is no way to implement FilenameFilter support with our current reliance on the Win32 common file dialog. Instead, we'll need to implement our own file dialog. This is outside the scope (or testing abilities) of a patch release, and will have to be done for the next major JDK release. Tom Ball, 5/15/97 There is neither a short-term fix nor an easy workaround for this problem. This is a problem which will definitely be addressed for 1.2, but cannot be for any maintenance release. The main issue is that support for FilenameFilter in the FileDialog class was never implemented on any platform -- it's not that there's a bug which needs to be fixed, but that there's no code to run nor was the design ever evaluated to see if it *could* be implemented on our target platforms. Rumor has it that the Motif FileDialog widget can be hacked to support FilenameFilter (I'm not a Motif engineer), but the Win32 FileDialog will need to be rewritten to support FilenameFiltering. That's because to support FilenameFilter, the FileDialog needs to issue a callback for each file it wants to display, which the FilenameFilter can veto. The Win32 common FileDialog doesn't have any way of issuing callbacks, but instead accepts simple wildcard patterns for suppressing files which don't match a certain pattern. That's a reasonable alternative to FilenameFilters, but that model isn't supported by our current API. So there are a couple of ways to address this in 1.2: write our own FileDialog which supports FilenameFilter and/or extend the FileDialog API to accept an array of wildcard strings for filtering. We probably shouldn't completely drop FilenameFilter support since it's useful for the Mac, but suffix matching works quite well for most other platforms. Rewriting the FileDialog is, to put it technically, a fairly hairy task -- easy to hack a first approximation, but it can be a real sinkhole getting the details right. I'd therefore vote that we extend the API to support suffix wildcarding, with the documentation saying that FilenameFilters are not supported on all platforms (we've done it before with other poorly thought-out cross-platform APIs, such as tear-off menus). Tom Ball, 6/18/97 (comment added/edited by Eric Rapin on 6/27/97) Unfortunately this is not going to get addressed for 1.2, other than having people use Swing's JFileChooser. It may be possible to hack the Win32 common file dialog to support FilenameFilter, by installing a hook procedure then selectively removing items from the ListView control that comprises the main interface, but this is extremely fragile and prone to breakage with future Windows releases. We could support the filter if we wrote our own dialog, but then we would lose some common dialog functionality (it's already changed on Win 98 to have a 'go to desktop folder' button). Also, the current API doesn't address things like how to add different file types to the type selection combobox. Instead of simple wildcard matching, we should try to come up with platform independent file typing, perhaps using MIME-types instead of suffixes. On the Mac, files are identified by 4 letter codes stored in the resource fork (like TIFF, PICT, WORD etc). OS/2 HPFS has file typing beyond simple suffixes as well. Even with suffix matching there are problems. On Windows, for example, .htm is used an extension for HTML files in addition to .html. Windows already has MIME <-> suffix matching (check out View->Options->File Types in the Explorer), though not all file types are registered with a MIME equivalent. For other platforms, we could have JVM vendors provide MIME <-> native type mapping in a .properties file perhaps. robi.khan@eng 1998-10-07 Microsoft has added a hook, OFN_ENABLEINCLUDENOTIFY, in Windows 2000 that will allow us to actually do this. The problem has been fixed for Windows 2000 in kestrel, and cannot be fixed for Windows 95, 98, or Windows NT 4.0. With the new hook, the dialog proc is given a WM_NOTIFY message every time a file is shown in the dialog. This allows us to call FilenameFilter.accept(). The return value from the dialog proc is not evaluated correctly in the current betas of Windows 2000, so that as we are able to allow custom file filtering, the value is not checked and does not indeed filter. Nevertheless, we anticipate Microsoft will fix this bug by FCS. In passing, I also noticed that the Solaris implementation does not quite work properly. Filename filtering works when the dialog is initially shown, but does not work as the directory hierarchy is traversed. I will file this as a separate bug report and reference the bug number here. michael.martak@Eng 1999-11-22 It turns out Microsoft may not ever fix this after all: http://msdn.microsoft.com/library/periodic/period99/logo.htm The relevant section is: BEGIN+++ Another new flag warrants a few words. OFN_ENABLEINCLUDENOTIFY works in conjunction with a hook procedure. The documentation claims that this flag lets you be informed about items that will appear in the folder's view. That's correct, but the feature is less appealing than it initially may sound. Once you turn the flag on and define the hook procedure, it starts receiving a CDN_ INCLUDEITEM notify message. The following pseudocode shows how to handle it: LPOFNOTIFYEX lpon = (LPOFNOTIFYEX)lParam; ò ò ò case WM_NOTIFY: switch(lpon->hdr.code) { case CDN_INCLUDEITEM: return MustInclude(lpon); ò ò ò } The MustInclude pseudo-function returns True or False depending on whether the item is to be included in the view. To let you identify the item, OFNOTIFYEX includes a pointer to the folder's IShellFolder interface and the PIDL of the item. So far, it appears to be a powerful feature that lets you filter the content of a view and decide which file objects a given user can see. Unfortunately, the dialog box always ignores your return value if the item has the SFGAO_FILESYSTEM and SFGAO_FILESYSANCESTOR attributes. In other words, if you're dealing with normal files and directories, or folders that are the parent of a file system folder (such as My Computer), by design the OFN_ENABLEINCLUDENOTIFY style doesn't apply. It works only with namespace extensions. a namespace extension, when designed to appear in the common dialog browser, usually obtains a ICommDlgBrowser pointer and calls the IncludeObject method to get the permission to show any of its items. The caller of the common dialog can now, to some extent, control the content shown by a namespace extension. +++END We will attempt to contact Microsoft developer support, but in the meantime, it appears that this will never be fixed on Windows. michael.martak@Eng 2000-02-24 Paid for a Microsoft developer support incident. I have gotten the following feedback from their representative: CASE_ID_NUM: SRX000224603173 MESSAGE: ********************** The message for you follows ************************ Heather asked me to call you and explain why OFN_ENABLEINCLUDENOTIFY cannot be used with the file system. This flag was specifically intended to be used with Namespace extensions, and explicitly not be involved with file system files. At the lowest level in the O/S, any attempt to include file system files and/or folders is blocked. This is by design. If you can tell me what you are attempting to accomplish, there may be another way to do it. *** I contacted their representative and explained our business case / need. In the meantime, they searched for a workaround to the dilemma: CASE_ID_NUM: SRX000224603173 MESSAGE: ********************** The message for you follows ************************I received your e-mail. I'll follow up on the feasibility of submitting a DCR (design change request), but I cannot predict if/when such a change could be incorporated. At the moment, the answer is "no, you cannot customize the common file dialogs with any kind of filtering, except file extension filtering." *** Microsoft's final response: CASE_ID_NUM: SRX000224603173 MESSAGE: ********************** The message for you follows ************************ I have evaluated your request, and I'm sorry to say it really doesn't qualify for the formal DCR procedure, since it isn't a "make or break" feature change. At this point, I can only suggest that you submit this request (along with your documentation) to ###@###.###. This alias is monitored, and the suggestions submitted to the appropriate product group for evaluation. *** I am closing this issue out as "will not fix". If developers need this capability in windows, I would suggest they contact microsoft through the alias mentioned above. All documentation in future releases should be changed to reflect that this does not work on windows. michael.martak@Eng 2000-02-29