Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RootFolder property doesn't work for modernize ForderBrowserDialog #3290

Open
Olina-Zhang opened this issue May 15, 2020 · 7 comments
Open

RootFolder property doesn't work for modernize ForderBrowserDialog #3290

Olina-Zhang opened this issue May 15, 2020 · 7 comments
Labels
🪲 bug Product bug (most likely) help wanted Good issue for external contributors
Milestone
Help wanted

Comments

@Olina-Zhang
Copy link
Member

Olina-Zhang commented May 15, 2020 •
edited by RussKie
Loading

  • .NET Core Version:
    .Net Core 5.0 from master branch: 5.0.100-preview.5.20262.7

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

Minimal repro:

  1. Create a Winforms .Net Core Application
  2. Add following code to show modernize folderBrowserDialog and set its RootFolder property to specific Folder 
        public Form1()
    {
        InitializeComponent();
        FolderBrowserDialog folderBrowserDialog = new FolderBrowserDialog();
        **folderBrowserDialog.RootFolder = Environment.SpecialFolder.CommonStartMenu;**
        folderBrowserDialog.ShowDialog();
    }
  3. Build and run application

Actual behavior:
RootFolder property setting doesn't work, please see following screenshot:
image

Expected behavior:
RootFolder should be changed in modernize folderBrowserDialog, see below screenshot in old folderBrowserDialog(.Net Framework behavior)
image
@RussKie RussKie added 🪲 bug Product bug (most likely) help wanted Good issue for external contributors labels May 27, 2020
@RussKie RussKie added this to the 5.0 milestone May 27, 2020
@weltkante
Copy link
Contributor

related: #3512 and #3513

@merriemcgaw merriemcgaw modified the milestones: 5.0, Future Sep 1, 2020
@RussKie RussKie added up-for-grabs-temp help wanted Good issue for external contributors and removed help wanted Good issue for external contributors up-for-grabs-temp labels May 5, 2022
@ghost ghost modified the milestones: Future, Up-for-grabs May 5, 2022
@ghost
Copy link

ghost commented May 5, 2022

This issue is now marked as "up for grabs", and we’re looking for a community volunteer to work on this issue. If we receive no interest in 120 days, we will close the issue. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@elachlan elachlan mentioned this issue Nov 15, 2022
Open
@elachlan
Copy link
Contributor

The code is hooked up for RootFolder only when AutoUpgradeEnabled=false. The modern view uses the IFileOpenDialog which as far as I can tell doesn't expose this functionality.

https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifileopendialog
https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifiledialog

@weltkante
Copy link
Contributor

weltkante commented Dec 12, 2022 •
edited
Loading

Could this be mapped to DefaultFolder in the new API? Or does DefaultFolder already have a separate property? Probably needs some experimentation to figure out a "good" mapping for the user experience.

@elachlan
Copy link
Contributor

DefaultFolder sets where the start location is. RootFolder basically limits the file system view to that folder only.

I suspect there might be another interface for a folder dialog.

@weltkante
Copy link
Contributor

I'm aware of the differences, I was just adding another option to the discussion, depending on how strongly people want to map the semantics of the user experience.

In my opinion RootFolder is less of a limiting functionality (since it runs under your own user account you could easily escape the limitation by creating an appropriate folder link) but it is more of a scoping functionality for the user experience, pointing the user to where they are supposed to start looking, especially since the tree will start collapsed by default it feels very much like a "starting point", so DefaultFolder seemed like worth considering for mapping the user experience.

It all depends on how the API is supposed to work - do you want a general purpose API that does a "best effort" of mapping the user experience - or do you want maximum control over the available features in each supported version? In the latter case your comment of the property not applying to the new version of the dialog is obviously more appropriate, and you only get appropriately detailed control by fully exposing each versions API directly instead of mixing everything into one API that tries to unify completely different concepts.

@elachlan
Copy link
Contributor

I don't really have a feeling either way. But I think the winforms team has a policy of exposing the functionality available in the WinAPIs as faithfully as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
🪲 bug Product bug (most likely) help wanted Good issue for external contributors
Projects
None yet
Milestone
Help wanted
Development

No branches or pull requests
5 participants
@elachlan @RussKie @weltkante @merriemcgaw @Olina-Zhang