<AWT Dev> RFE: Windows awt FileDialog in JDK9

[Hendrik Schreiber]

> On Mar 9, 2016, at 10:45, Artem Ananiev <artem.ananiev at oracle.com> wrote:
> 
> as far as I remember, AWT team investigated the new file dialog, when Vista was released. It looks fine, but there's an issue: it doesn't provide a way to implement
> 
> FileDialog.setFilenameFilter(FilenameFilter filter)
> 
> method. The chances are Microsoft has introduced new APIs for it since then, otherwise this method should be protected with a "isSupported" check.


As far as I can tell, Vista still had a method called SetFilter (https://msdn.microsoft.com/en-us/library/windows/desktop/bb761826(v=vs.85).aspx) which could be used to implement this, but it was removed in Windows 7.
The recommended replacement is SetFileTypes (https://msdn.microsoft.com/en-us/library/windows/desktop/bb775980(v=vs.85).aspx), which only accepts type patterns (I guess something like "*.exe”).

This means, the current FileDialog.setFilenameFilter(..) cannot be implemented, just like Artem stated.

Bummer.

And frankly, making that method unavailable (even protected by isSupported), would probably annoy quite a few people.

I can come up with two options to have it both ways (maintain compatibility and use the new dialog):

== Option 1

Use the old common dialog-based implementation, whenever setFilenameFilter() was called. Otherwise use the new implementation and document this behavior in the javadocs.

== Option 2

Introduce the following inner classes to FileDialog (just an outline):

public static class FileType {
    public FileType(String description, List<String> extensions);
    // convenience constructor
    public FileType(String description, String... extensions);

    public String getDescription();
    public List<String> getExtensions();
    ...
}

public static class FileTypeFilter implements FilenameFilter {
    public FileTypeFilter(List<FileType> fileTypes); // do you guys prefer collections or arrays?
    // convenience constructors
    public FileTypeFilter(FileType... fileTypes);
    public FileTypeFilter(String description, String... extensions);
    public List<FileType> getFileTypes();
    ...
}

FileTypeFilter can easily be mapped to SetFileTypes. So when a user calls setFilenameFilter() with a FileTypeFilter as argument, we can still show the new dialog without having to modify the FileDialog API (well, except for adding two inner classes).

Just like in Option 1, whenever a FilenameFilter is set, that is not also a FileTypeFilter, fall back to the old implementation.
This behavior, obviously has to be documented.


The drawback for both options would be, that we have to maintain an old and a new implementation. That always sucks.

Cheers,

-hendrik