The reason I haven't submitted a PR myself is that I wasn't able to test the code. Did you manage to run it from an app?

It looks like the only thing you changed is the name - I used PickFolderFileDialog because it's a file dialog with a pick folder flag. I think an "open" operation on folder is a bit misleading, what would be the corresponding save folder dialog?

That said, I am not that picky about the name, as long as we get the dialog!

I think an "open" operation on folder is a bit misleading

Tell this Microsoft, they have chosen "OpenFileDialog" for picking/selecting a file instead of "SelectFileDialog". Thus "OpenFolderDialog" matches the line of "OpenFileDialog". On Winforms its called "FolderBrowserDialog". And on the Windows API Code Pack they called it "CommonOpenFileDialog" allowing setting a property "IsFolderPicker" to true.

So if even Microsoft haven't followed any line, there is no ultimate solution for its name. I for myself think that (existing) "OpenFileDialog" and (new) "OpenFolderDialog" seems quite nice together, while calling one "OpenFileDialog" and the other "FolderBrowserDialog" is not matching at all.

Anyway, we have several ways of calling it and there is no good or bad one. They all make sense, its just a matter of taste. I can rename it if necessary.

@Symbai having open and save file dialogs separate instead a common select file one has some advantages, such as remembering different recent locations for the two tasks separately.

I am sure the team will pick a name they see best fit.

Hi @Symbai. We are still establishing an API review process for WPF. @SamBent will likely be the final approver, but I will follow up when we have confirmation. Thanks.

Thanks for the update, I appreciate that. I can wait, take your time.

Adding @MikeHillberg for API review...

What's the status on this?

What's the status on this? Is this ever getting reviewed by someone either merging it or telling me what exactly I have it to change it to so it will be merged?

Closing as WPF team is unable to review for 5 months and refuses to tell whats the problem. If anyone else wants to do this to themselves, go ahead. I'm giving up on this repo and this team, sorry.

What a pity. It seems the WPF team has very little resources or little interest. WPF feels dead to me :(

Reopening issue, I left a comment for @Symbai.
We are very much interested in the community PRs, we're just heads down making progress on open sourcing the test repo which is vital for accepting community PRs.

Let us know if you'd like to resubmit, looks like your repo PR has been deleted.

I am happy to resubmit if needed, but I think some design discussion should take place first. Is that also waiting for the testing infrastructure?

Based on the previous PR I don't believe this change would require the test repo for finalizing it. I'd appreciate if you could bring back the design main points and give us and the community clear options. @MikeHillberg brings some good points, would be good if you could address them. Thanks @miloush!

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.

@miloush That's a great summary of the design discussion required for this PR and I think you've covered everything.

Here's my personal opinion on this discussion:

1. Inheritance
My favorite is inheriting from a new class that inherits from CommonDialog. Both FileDialog and the folder dialog class would inherit from it. I wouldn't move anything public from FileDialog to the new base class. I would only move the private/protected/internal members to the base class and duplicate the public members for compatibility.

If we need full compatiblity and zero API changes to FileDialog (No new base class), we could either use a static class with the shared code or an internal implementation class. By "internal implementation class", I mean a new internal class that contains the shared implementation code from FileDialog and the new folder dialog. The public API would forward their calls to the internal class.

I personally don't like option c). There is a bunch of API that would do nothing and I don't think that it's very developer-friendly.

2. Naming
I always disliked the name FolderBrowserDialog in WinForms because I don't think that it's very intellisense-friendly. Having OpenFolderDialog and OpenFileDialog would make it easier to see the two types of Dialog in intellisense.

3. Legacy support
I wouldn't add any new code to support pre-Vista dialogs. .Net 6 does not support Windows XP and I don't see the team adding it back in a future .Net version. I would just let it fail with an exception that the Win32 API for Vista dialog does not exist if somehow someone was able to run a WPF app on a pre-Vista Windows.

@fabiant3 You wanted to re-open this PR, right? It looks closed to me :)

What @miloush and @ThomasGoulet73 posted sounds smart to me. On the other side, I'd be happy to have any WPF option at all. This piece is missing for many years. Don't give up on this! 👍

I tried to look more into the splitting inheritance option and I don't think it is that beneficial after all if we can't move around public members - they would have to be defined on both the FileDialog and the new intermediate. If we wanted to keep them non-public on the intermediate, then we would have a public class with no members, which is not great either.

The whole picking folder capability of the file dialog feels like stitched in as an after-thought, and pretending on the WPF side that there is a clean design is a fallacy. I am now actually inclined to just add PickFolders property on the FileDialog and call it a day. That's what the underlying model is anyway.

• On Windows Vista, the save file dialog supports the pick folders flag, and it lets users to enter a non-existing path, i.e. a folder to be created (this support has been removed on later Windows versions)
• The Multiselect option kind of works for folders in the sense that the dialog allows you to select multiple things in the UI, however, you are not allowed to confirm such selection.
• The legacy browse for folder dialog has the ability to display files when selecting a folder. If this feature is added to the new dialog too, then the filter properties become relevant.

These are the current public properties on the FileDialog:

Applicable to folders:

• CustomPlaces
• DereferenceLinks - whether links to folders are followed or not allowed
• FileName - e.g. C:\Users\Thomas
• FileNames - would always have 1 item at the moment
• InitialDirectory
• Options
• SafeFileName - e.g. Thomas
• SafeFileNames - would always have 1 item at the moment
• Tag
• Title

Doing something, but wouldn't be necessary for folders:

• AddExtension - internal WPF flag to ensure the file/folder name ends with an extension
• DefaultExt - the extension to add by default
• ValidateNames - this one is a red flag, the WPF documentation says "indicating whether the dialog box accepts only valid Win32 file names." which is how the OFN_NOVALIDATE flag works in the legacy file dialogs. However, for the Vista dialogs, the FOS_NOVALIDATE flag means "check for situations that would prevent an application from opening the selected file, such as sharing violations or access denied errors."). In addition to the dialog behavior, WPF uses the flag for adding extensions and prompting for overwriting existing files.

Valid but currently without any effect:

• CheckFileExists - only existing folders are allowed nowadays
• CheckPathExists - only existing folders are allowed nowadays
• RestoreDirectory - applicable to legacy dialogs only, not used in Vista dialogs

Invalid (the native call returns an error):

• Filter
• FilterIndex

So in fact @ThomasGoulet73, there isn't that many properties that would do nothing, and all of them would have either worked in the past or might work in the future/on other platform.

As for legacy implementation, I am not quite sure what is the support requirements for running on a supported version of Windows but in a compatibility mode.

This should'nt be closed... MS should fix it...