> 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