United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4031440 : FileDialog doesn't call FilenameFilter.accept()

Details
Type:
Bug
Submit Date:
1997-02-11
Status:
Closed
Updated Date:
2012-10-11
Project Name:
JDK
Resolved Date:
2000-02-29
Component:
client-libs
OS:
generic,solaris_2.3,solaris_2.4,solaris_2.5,solaris_2.5.1,solaris_7,windows_95,windows_nt
Sub-Component:
java.awt
CPU:
generic,x86,sparc
Priority:
P4
Resolution:
Won't Fix
Affected Versions:
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
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description

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);
        pack();
        show();
    }

    // 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;
        cont.add(c1);
        gbl.setConstraints(c1, c);

        c.gridwidth = GridBagConstraints.REMAINDER;
        c.weightx = 1.0;
        cont.add(c2);
        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);
            fd.setDirectory(tfDirectory.getText());
            fd.setFile(tfFile.getText());
            fd.setFilenameFilter(this);
            fd.show();
            tfDirectory.setText(fd.getDirectory());
            tfFile.setText(fd.getFile());
            
            // 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  -  ###@###.###
======================================================================

                                    

Comments
WORK AROUND



Name: mc57594			Date: 02/10/97


Unknown
======================================================================
                                     
2004-06-11
PUBLIC COMMENTS

FileDialog doesn't call FilenameFilter.accept().
                                     
2004-06-10
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
                                     
2000-02-29



Hardware and Software, Engineered to Work Together