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

}



======================================================================

Unknown
======================================================================

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.

  xxxxx@xxxxx   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.

  xxxxx@xxxxx   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.

  xxxxx@xxxxx   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   xxxxx@xxxxx  . 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.

  xxxxx@xxxxx   2000-02-29

We have a requirement to use the FileDialog to
locate and select from a list of directories on 
UNIX and Windows (NT and 95).  We are concerned
that a simple pattern match filter would not
be able to express this.
Ideally, we would like to see a simple boolean 
property that would modify the behavior to select
only directories. The FilenameFilter is acceptable
if it works on both UNIX and Windows; but it looks
like it will never work on at least Windows.  A
pattern match would also be acceptable if it we
could create a pattern that selects only 
directories. 

You can set the filename to something like *.txt
on Win95/NT to do wildcard-filename-filtering.
*.txt;*.html accepts only txt and html files.

It is definitely needed here, but I would accept it to be postponed for JDK1.2.

Setting the filename to *.txt (or whatever) does work for NT, but not for Unix
-- an array based filtering mechanism would be good.  While we're at it, we
also need a new file-dialog type per schesney so that we can choose
directories....

Not fixed in 1.1.5/solaris 2.6
I could do my filtering by setting the wildcard,
but I haven't found how to set it from the API.

Selecting a directory is a basic feature that is not handled by wildcard
filtering. If this were an option somehow, wildcard filtering would be an
acceptable near-term workaround for the lack of true filtering.

You know, this JDK bug showed up in the first
Java program I ever wrote.  It's really visible,
since selecting a file is a BASIC application
feature.  I like the model of letting applications
do the filtering; providing a reusable filter
class to do pattern matching (xyz*, *.xyz, etc)
is a lot better than saying you can _only_ do
pattern match based filtering.

I have written my own FileDialog class for Sun
Solaris ( with Filter ). I can give you the sources
files ( It's free !!!)

It's surprising that a feature of the language 
as fundemental as a FileDialog could be written and
released knowing that it has not been implemented.
I wonder what other parts of the class structure 
don't work ! :(

Windows file dialog allows me to select multiple files with the aid of the
modifier keys (control &shift).  Can I do this with the FileDialog?  If so,
it escapes me.  If not, it would be a nice feature.

Some form of filter is quite critical for us at
present. We would be content with wildcards or
a FilenameFilter implementation but would have
liked to see it sooner rather than later. :-)
Naturally!

Good news for those that use MRJ 2.0.  FilenameFilter
works great with it!!!  So please sun...don't get
rid of FilenameFilter.

Maybe a new method should be added that tells us
whether or not the file-dialog accepts a filename
filter. This way our code could be written to use
wildcards on shitty platforms that don't support
it, and use a true filename filter on those
well-thought-out platforms that do.  
As an example, MouseEvent.isPopupTrigger() works 
this way. It lets my code adopt different behavior
on different platforms.
Here are some suggestions for the method name:
boolean supportsFilter()
boolean filterWorks()
boolean isShittyPlatform()

We would also like to see the FileDialog to select only directories.

I wonder, that such an important feature of the 
FileDialog is not implemented in the JDK1.1.5;
I hope this will be fixed soon ... 
( wildcard-filename-filtering would also be ok)

To avoid the problem of suffix matching on the Mac you could write content-type
(MIME) based methods. For example, setFilter("image/*").
See also java.awt.DataFlavor

Has this been fixed in 1.2 yet? Does the swing FileChooser fix this? 

I think it FilenameFilter is an important concept
that simply cannot be thrown out. Selecting only
directories or certain files is an important
ability that is worth providing and looking into
further. 
Stating that FilenameFilters are not supported 
on all platforms in the documentation as a
solution leaves a sour taste about Java. Its
shaking the very foundation it wants to lay.
required 

Filename filtering is a very essential feature.  Thelso
ability to pick directories only is also needed in
our apps.  Simple wildcard filtering would be acceptable
for a short-term fix.  

As "db" also found, this showed up in my very first test program.
Annoying! The alternative JChooser filters OK, but is unacceptably slow to
appear (NOT because of the filtering!).
Having a working file filter is a key part in making Java useful for writing
standalone applications. For Mac, I would also appreciate being able to check
the "four-letter" file type and creator fields.

A problem with an important feature like FileNameFilter needs to be fixed very
soon.
Has this bug been fixed in JDK1.2 Beta versions.

JFileChooser has its own (worse) problems
- at least in 1.0.x

I entered code directly from "The Java Class Libraries, Second Edition,
Volume 2", a 
Sun book, and code doesn't work as written.  I'm just learning Java, but it is
a concern 
that the book didn't mention FileDialog setFilenameFilter problem in WIN95 as
part of 
the example.  I did try addNotify(), and the filter seemed to work, but the
format of the
FileDialog changes to a non standard appearance.

The use of the FilenameFilter is a basic
requirement, it is documented, and needs to be
fixed.

We want a feature in the FileDialog, that will let the user select only
directories. We want to use only AWT. So if possible, some option like
JFileChooser.setFileSelectionMode() function may be provided.

There is a seperate bug report asking for a
directory chooser - no. 4037524.
Sun, please fix both these bugs.

AWT will very soon be obsoleted by JFC. Is this
bug still relevant?

Why don't you guys cooperate with Microsoft once in a while? Why don't you add
an overloaded version of setFilenameFilter() that will accept a string that
represents an MS Windows filename filter criterion, and have that version of
setFilenameFilter() work on Windows 32-bit systems?

Also, using the FileDialog in SAVE mode, on WinNT, it would be very nice to be
able to supply those "save as type" settings.  Then you don't have to
kludge in some equivalent device into your user interface, when a perfectly
good one already exists on the platform.

We have this bug in 1.1.6, Solaris.

How about putting this in the documentation?
Something like "THIS DOESN'T WORK SINCE WE DIDN'T
BOTHER TO IMPLEMENT IT."

So I wasted half a day trying to do something that was never possible in the
first place.
Can't such things be mentioned in the documentation?

I am also disapointed about not working 
FileNameFilter with FileDialog under win32.
It does not work in JDK1.2 either!
And the Filechooser is not working correctly:
No switch between "details & lists",
leftover Debug-printout during runtime
and the worst: no ability to choose a differnet
language than englisch.
Kurt

I absolutely agree with dwegner and mfarrent.
Folks at Sun, please put that into the documentation  so that people don't
waste their time.

setFile("*.java"); seems to work under w95.  
(jdk 1.1.7a, jview)
J++ wfc has a fully featured file dialog;
Haven't compared it with swing's, but I hope
the swing team had the sense to snatch the 
worthwhile ideas from it.
 [ miles ]

This BUG is from JDK1.0 to JDK1.2
Why not tell me in the help docs,
so I will not waste my time on this
problem.
I hope all known bugs should be 
wroten in the help docs.

I strongly recommend that you include a note in the 
javadoc documentation and your documentation web pages
that indicate methods that are not implemented.  It would
be better to know that a method does not work BEFORE using it
rather than find out after writing 100 lines of code dependent
on it and spending hours trying to find the bug. 

I know that this has been mentioned repeatedly but I think it's important 
enough to mention again.  PLEASE ADD DOCUMENTATION when you know something
is not implemented or isn't working correctly. This will save developers a lot 
of time and headaches.

Wow, look documentation on this feature THAT WAS NEVER IMPLEMENTED!  How many
years of programmer time has been wasted because sun won't take 2 minutes to
stick this in the documentation files.  I would think after reading all these
complaints I wouldn't have to waste so much time trying add a FilenameFilter, I
guess I need to stop thinking.

Here's a thought. Why not deprecate the 
getFilenameFilter and SetFilenameFilter methods,
if said functionality is unfeasible. Or introduce
a new tag for functions that don't yet do what 
they claim to. How about using the @deceptive or 
@justkidding tag? How long has it been now?

Have you noticed that Swing's JFileChooser's dropdown doesn't show the items
indended to seem like a tree as Windows does at its File Dialog's dropdown box?
And that "Desktop" isn't the root of the tree as the user would
expect, but is hidden somewhere in the Windows dir (its real location)

C'mon Sun, JFileChooser looks terrible under Win32, and its extremely slow
(plus the fact that it insists on scanning my zip drive when there is no disk
there). Fix the original one, or re-document the methods to include the comment
"NFG"

Well the good news is maybe Sun will finally fix this for windows when W2K gets
released.  W2K has new style bits for the OPENFILENAME structure that they
could use to do the filtering fairly easily.
So after three years this bug might actually be fixed.

Well, since JFileChooser does not work anymore
(bug #4271669) it seems like FileDialog is the
only alternative that is left anyway.

HELLO?!!  Unhappy programmer number 25349 reporting:

If you know it's broken and you don't intend to
fix it, you must DOCUMENT this fact!

I've just wasted the past two hours puzzling over
my code, poring over your documentation, and even
digging out the API sources...

Finally, I discover the reason why my FilenameFilter
isn't being called...  From the BUG DATABASE!

And the problem was reported NEARLY THREE YEARS AGO!!!

Grrr...

This is shoddy, unprofessional work!
You should be ashamed.

You MUST add some mention of the shortcomings of
the FileDialog to the API docs!

I totally agree:
This is shoddy, unprofessional work!!!

At least fix your documentation!

While you're at it, document that fact that you can use wildcards to filter in windows.

Too bad the original Java design won't work, because sometimes you want to look at the
magic number, not the extension.  Oh well, I'm switching to Linux anyways.

yet another programmer who has wasted time trying to find out while filename filters won't work with file dialogs ...
why can't you say so in the documentation if it won't be fixed ...

And another programmer wasting a lot of valuable time on trying to get something so simple as a file dialog 
filename filter working, only to find out that it's not even implemented - and of course no mention of this 
exists in the documentation!

Add my name to the list of those who have wasted 2+ hours trying to get this
BASIC functionality to work.  FIX IT or WRITE IT UP, it REALLY IS JUST THAT
SIMPLE.

thompson

You can add me to the list of frustrated programmers...

Thank you for documenting the fact that it doesn't work on 
Windows! I've been waiting for that a long time. Why don't 
you guys support filtering by regular expressions and 
wildcarding? Unix does it, and so does Windows. Get rid of 
this filtering scheme. Most programmers have no need to 
filter by date, attributes (permissions), or any other file 
field. Even the equivalent of a few predefined wildcards 
would be good, like MIME. There is no need to worry about 
this stuff working on OS/2 because IBM will no longer 
support this old operating system. I don't think this a 
Windows bug, I think its a Mac bug. Having Java or your own 
program go through all the files for filtering is way too 
time consuming, especially when a novice programmer does 
this. Please consider implementing a proper filename 
filtering scheme API with regular expressions, wildcards, 
or at least MIME.

Oh, and Microsoft and Sun helping (i.e. hindering) each
other to sort this problem out. Ever heard the expression
'The blind leading the blind'?

Quote :
"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)."

Finally someone at Sun who is honest about the state of
Java. Note that this evaluation comment was added in June
1997 - 3 years on and not much has changed really - I
particularly liked the bit about poorly thought-out APIs. So
much for cross-platform and write once, run anywhere. More
like write once, run away.

I just wanted to add my name to the list of people who have tried to get the filenamefilter to work with 
FileDialog and have found out that it doesn't work.  I also tried the JFileChooser (or whatever it's called in 
Swing), but found it to be slow and visually unappealing.  I sincerely hope this gets fixed.

After some jerking with this component under Windows 95 (4.00.950 B), I found that it worked for me if I 
specify the file masks like that:

dlgFile.setFile("*.csv; *.ini");

It still does not display correctly (in "Files of type" combobox it says "all files only", and displays my mask in 
initial "file name" edit box), but it only allows you to choose INIs or CVSs in this case.

May be this would help someone.

2Sun: poor job. You should have it documented, it would save lots of time for everyone.

This is terrible. Can't believe such a simple file dialog 
filter is not implemented in Java. Tried many times with 
this filename filter, only to chance upon this page that 
this is a bug! What a waste of time...

I just want to add my input to this list of complaints about the
lack of documenation and functionality of the AWT "file
selection dialog" on Windows systems.  I also want to wish
you a nice day.

Submit Date  Feb 10, 1997 

Description  FileDialog doesn't call FilenameFilter.accept().

State  Closed, will not be fixed (2000-02-29)

2002-09-12, I left Java 3 years ago to things that actually 
works or can be fixed (read : perl and assorted GUI toolkits), 
man that was my smartest move in years...

Ok, so the docs are in finally. But lets face it, JFileChooser, 
like many other Swing components is just complete and uther 
rubbish if you want a system dependent look. I have spent 
countless hours discovering bugs and not yet implemented 
stuff you can't even begin to imagine (take a look at the finer 
points of java.text and java.awt.font etc and you'll find true 
gems of utter incomptence).

They're finally cleaning up there act it seems by providing 
1.4.1 which is a pure bugfix release but guys ... it's way too 
late. Deprecate it or fucking remove it (it won't break code 
cause it never ever worked anyways)

The is totally pathetic.  Even SWT has implemented this without any problems.