In my opinion the switching to old/new file dialog should be presented
in more explicit way. The automatic fallback may cause unexpected
behavior. May be it is worth to introduce a new system property to
regulate the file dialog version.
--Semyon
On 3/9/2016 3:44 PM, Hendrik Schreiber wrote:
On Mar 9, 2016, at 10:45, Artem Ananiev <artem.anan...@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
