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
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.
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.
It turns out Microsoft may not ever fix this after all:
The relevant section is:
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;
The MustInclude pseudo-function returns True or False depending on
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
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.
We will attempt to contact Microsoft developer support, but in the meantime, it appears that this will never be fixed on Windows.
Paid for a Microsoft developer support incident. I have gotten the following feedback from their representative:
********************** 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:
********************** 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
Microsoft's final response:
********************** 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
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.