Add OpenFolderDialog v2 by Symbai · Pull Request #4039 · dotnet/wpf (original) (raw)

Right. So, from my point of view there are basically 3 things to decide:

1. Inheritance

The options were:
a) no ancestor
b) inheriting from CommonDialog
c) inheriting from FileDialog

I am against a). It is a common dialog that everyone expects to be shown using ShowDialog, and that will have an owner window, which is basically all that CommaonDialog provides.

From these options, I prefer c). It is a file dialog after all, and there is a lot of code in FileDialog that would need to be duplicated. This includes extracting and validating the paths, hook procedure, OK confirmation event, support for custom places, and some of the flags. As @MikeHillberg pointed out, some of the flags do not apply, and the legacy dialog would need to be overridden if needed. However, if we go for c), the new code is very lightweight and mirrors the Win32 implementation (which is also only a flag on file dialog).

There are other options too. We might not want to do a breaking change moving properties around, but there might be a possibility to split the inheritance chain, that is, OpenFileDialog > FileDialog > something new > CommonDialog. The something new could be for example CommonFileDialog, where most of the FileDialog's internal code would be moved and that would not have the unnecessary properties. Then the new dialog would directly inherit this new intermediate. If this is an option from compatibility point of view, I am all up for it.

2. Naming

The options were:
a) FolderBrowserDialog. This is a name WinForms uses, based on the legacy shell API.
b) PickFolderFileDialog. This was based on the fact that it is a FileDialog with a pick folder flag, for consistency with OpenFileDialog and SaveFileDialog. If we split the inheritance chain, PickFolderDialog would make more sense.
c) OpenFolderDialog. This was to match OpenFileDialog.

I don't see any rationale for a) in a new WPF code. My worry about c) was that there is no "open" operation on folder involved and there would be no corresponding "save" operation/dialog, but as stated above I am quite easy between b) and c).

3. Legacy support

Windows XP which .NET Framework version of WPF supports does not have the common dialog APIs. The options are:

a) throw PlatformNotSupportedException. If this is going to .NET Core only, then this is a valid and easy option.
b) implement fallback using legacy SHBrowseForFolder API. Note that this has a non-trivial amount of native types to include.
c) call the WinForms implementation

If anyone thinks I forgot something, feel free to chime in.