Dialog cancel consistency

Describe the bug The file dialogs (OpenFileDialog, SaveFileDialog, and OpenFileDialog) do not have consistent return values when pressing cancel. On windows, I get OpenFileDialog returning empty array, SaveFileDialog returning null, and OpenFolderDialog returning an empty string. On linux, all of these return null when pressing cancel.

To Reproduce Open different dialogs on different platforms, press cancel on them, and look at the return values.

private async void Test()
{
    OpenFileDialog ofd = new OpenFileDialog();
    string[] ofdRes = await ofd.ShowAsync(this);

    SaveFileDialog sfd = new SaveFileDialog();
    string sfdRes = await sfd.ShowAsync(this);

    OpenFolderDialog old = new OpenFolderDialog();
    string oldRes = await old.ShowAsync(this);

    response = $"openfile: {SetName(ofdRes)}, savefile: {SetName(sfdRes)}, openfolder: {SetName(oldRes)}";
}

private string SetName(string text)
{
    if (text == null)
        return "[null]";
    else if (text == "")
        return "[empty]";
    else
        return $"\"{text}\"";
}

private string SetName(string[] textArr)
{
    if (textArr == null)
        return "[null]";
    else if (textArr.Length == 0)
        return "[empty array]";
    else
        return $"\"{string.Join(", ", textArr)}\"";
}

Expected behavior Should be consistent across all platforms. I’m not entirely sure what the cancel values for these dialogs are supposed to be. Maybe all null like on linux?

Screenshots

Windows Linux

Desktop (please complete the following information):

• OS: Windows, Linux (PopOS w/ XFCE)
• Version 0.10.6

Additional context

[YgorSouza]

One argument for returning empty over null is that you wouldn’t need to change anything later if you decided to enable nullable reference types, whereas if you return null you have to change the return type to string? and string[]? and that would be a breaking change.

[workgroupengineering]

Personally I would expect null string as default and empty array as default. Having nullable array is not good practice usually.

On PR #6160 i used Linux behavior .

@grokys @kekekeks What behavior do you recommend?