Winforms: FileDialog.InitialDirectory does not work

Created on 26 Jun 2020  ·  10Comments  ·  Source: dotnet/winforms

.NET Core Version:
master

Have you experienced this same bug with .NET Framework?:
yes

Problem description:
FileDialog.InitialDirectory doesn't seem to work? It works for the classic dialog, but modern dialogs seem to ignore it, even though there is source code handling it. Debugging the source seems to throw FileNotFoundException when calling GetShellItemForPath. Might be an interop mistake?

Expected behavior:
FileDialog.InitialDirectory should actually set the directory.

Minimal repro:
Create and show an OpenFileDialog with a non-empty InitialDirectory (make sure you get the modern version of the dialog)

bug regression waiting-review

All 10 comments

When fixing this, there is also desire to support special shell paths like "my computer". Might want to make sure that the fixed code understands these special paths when passing the string to shell API for translation, otherwise new API would be required to support them.

Also see #3512 for adding InitialDirectory to FolderBrowserDialog, in case the API suggestion gets accepted before this is fixed, otherwise both can be done together.

From yesterday rc2 blog post:

System.Windows.Forms.OpenFileDialog. Setting a value for the “InitialDirectory” property has no effect when running ShowDialog. Works fine with .NET Core 3.1.

Might want to reclassify as regression then, assuming 3.1 already used the new Vista dialog. (If 3.1 was still using the classic dialog, as mentioned above this still works.) My own test above already was against master so I didn't test 3.1 at all. Like mentioned above it fails during shell interop, might be interesting if 3.1 has this shell interop or is using different code.

Yes, it's regression from 3.1. Dialogs are same, 3.1 works, 5.0 - not.

Snipaste_2020-10-14_12-27-31

Repro: OpenFileDialog.zip

Good to be fixed before 5.0 release. @RussKie ?

Good to be fixed before 5.0 release.

Sorry, .NET 5.0 is complete. This _may_ meet a servicing bar for 5.0.x. /cc: @merriemcgaw

Sorry, .NET 5.0 is complete. This _may_ meet a servicing bar for 5.0.x.

_Complete_ for regression fixes on rc?
I am not sure about modern/classic dialogs, but simple using of OpenFileDialog produces same dialog look on Win10 for netcoreapp3.1, net5.0-windows and net472. And InitialDirectory not working only in net5 :( So this is pure regression from .net framework and .net core3...

I'm going to have someone take another look at this ASAP. I can't promise we can get it into 5.0 GA simply because we're very close to locked down. Once we know what the root cause is and the risk of a fix we can determine if we can get it through in time for GA. If we can't, we can certainly look to it for servicing.

I'm going to have someone take another look at this ASAP. I can't promise we can get it into 5.0 GA simply because we're very close to locked down. Once we know what the root cause is and the risk of a fix we can determine if we can get it through in time for GA. If we can't, we can certainly look to it for servicing.

Thank you. Let's hope, because only this bug alone is enough (for us) to not switch to 5.0 :(
P.s. Need to correct labels...

Investigating

_Complete_ for regression fixes on rc?

Tthere is a release process, and we're just one of the outer nodes on the graph. It takes weeks to prepare a public release, so we do have hard deadlines after which no change is accepted, and go into a subsequent servicing release.

Was this page helpful?
0 / 5 - 0 ratings