Add OpenFolderDialog

[Symbai]

Fixes #438

Usage:

var dialog = new OpenFolderDialog();
if (dialog.ShowDialog() != true) return;
MessageBox.Show(dialog.FileName);

var dialog = new OpenFolderDialog { Multiselect = true };
if (dialog.ShowDialog() != true) return;
foreach (var directory in dialog.FileNames)
{
    MessageBox.Show(directory);
}

[ryalanms]

/cc @fabiant3 @SamBent

[miloush]

Sorry, this is just a bad copy&paste implementation that does not fit into the framework.

[Symbai]

Sorry, this is just a bad copy&paste implementation that does not fit into the framework.

This was requested since nearly 2 years. Nobody bothered to add a PR for it, including yourself. Instead of downvoting my PR and calling it "bad" without giving any argument, you should make it better then. At least I'm trying to solve the problem, what's your excuse?

[ryalanms]

Thanks, @Symbai and @miloush. We will review this during the next triage session.

[lindexi]

Should we catch all exception?

[lindexi]

May I know what "Mru" is?

[miloush]

most recently used

[lindexi]

Thank you. But I don’t think abbreviations are suitable here.

[Symbai]

Names were taken from WindowsAPICodePack

[miloush]

@Symbai My excuse is quality expectations. I am not submitting a PR if I cannot test the code is even working. If there is anything worse than a project not accepting PRs it is a project accepting anything. The folder dialog seems to be a heated topic and there is a pressure from the community to demonstrate commitment, and since it was flagged for review I wanted to note that this implementation does not meet the expectations of at least some of us.

That said, I could have been more constructive in the reasoning, so please accept my apologies, here are some of the reasons I am unhappy with this PR (in no particular order):

• It is a file dialog (and common dialog), but the class is not in the file dialog hierarchy.
• It is in different namespace than the other common dialogs, and you are introducing a new root namespace that is not used for anything else.
• Introducing enormous number of types that already exist in the framework (and worryingly with different signatures), have you seen e.g. ShellProvider.cs?
• All types in single file
• Every property has an automatic backing field, taking unnecessary amount of memory for what is effectively a flag number.
• Inconsistent type accessibility (internal vs unspecified), and naming conventions differ from the existing code
• No support for custom places
• No hooks to process the dialog notifications
• No security checks, no threading checks, no error handling.

Here is an alternative implementation with minimal impact on the existing codebase: master...miloush:PickFolderFileDialog

[Symbai]

Here is an alternative implementation with minimal impact on the existing codebase: master...miloush:PickFolderFileDialog

Great, go ahead and make a PR then.