How can I make RadOpenFolderDialog let me select *just* a custom place?

5 posts, 0 answers
  1. Joe
    Joe avatar
    93 posts
    Member since:
    Nov 2017

    Posted 16 Jun Link to this post

    I'm using RadOpenFolderDialog with the new filters capability to show only my "custom places" on the left side of the dialog;   I need to force the user to only be able select from a list of configured folders or children of them.   But there is a problem.

    When filtering is enabled in this way, the dialog always requires the user to select something inside of the selected custom place.  You can't just click the custom place on the left.  The "Select Folder" button doesn't enable.    You then have to go to the right hand pane and click one of its subfolders before the "Select Folder" button enables.

    This is a problem.  Some of my custom places don't have subfolders within them so sometimes there is nothing on the right to select.

    If I do not have filtering enabled then selecting the custom place does enable the "Select Folder" button.

    For example, I ran my code with just one custom place configured.  "F:\Remote"  I made the filter log which folders it allows and which it denies.   I've attached an image (snap18.png) that shows what it looks like when I select that custom place.   Nothing enables.

    Here is my dialog code.  The filter only allows folders that are equal to or subfolders of one of the custom places:


    void SelectFolder(List<string> configuredFolders)
    {
        var dlg = new Telerik.Windows.Controls.RadOpenFolderDialog
        {
            Multiselect      = false,
            Owner            = Application.Current.MainWindow,
            Header           = "Select a folder"
            ShowNetworkLocations = false,
        };
        foreach (var f in configuredFolders)
        {
            dlg.CustomPlaces.Add(f);
            Log.Debug($"Added custom place {f}");
        }
        // Hook up to the DirectoryRequesting event to prevent folders
        // we don't want to allow
        dlg.DirectoryRequesting += (sender, args) =>
        {
            // Get a normalized file path for easy comparison
     
            var name = FileUtils.NormalizePath(args.Directory.FullName);
            // Only allow folders that are not equal to or a child of one of the
            // configured folders
            if (!folders.Any(f => FileUtils.IsParentOrEqual(f, name)))
            {
                Log.Debug($"DirectoryRequesting: DENY {name}");
                args.Cancel = true;
            }
            else
            {
                Log.Debug($"DirectoryRequesting Allow {name}");
            }
        };
        var result = dlg.ShowDialog();
        // Do something with the result
    }

     

    Here is the log output

    GelSight.Mobile.App: 21:28:53.241 [1] DEBUG - IsLive: Device IsLive => False
    GelSight.Mobile.App: 21:28:53.273 [10] DEBUG - ThreadProc: Live thread proc stopping
    GelSight.Mobile.App: 21:28:53.478 [1] DEBUG - .ctor: Added custom place F:\Remote
    GelSight.Mobile.App: 21:28:53.509 [1] DEBUG - .ctor: DirectoryRequesting: DENY C:
    GelSight.Mobile.App: 21:28:53.538 [1] DEBUG - .ctor: DirectoryRequesting: DENY D:
    GelSight.Mobile.App: 21:28:53.570 [1] DEBUG - .ctor: DirectoryRequesting: DENY F:
    GelSight.Mobile.App: 21:28:53.601 [1] DEBUG - .ctor: DirectoryRequesting Allow F:\Remote
    System.Windows.Data Error: 26 : ItemTemplate and ItemTemplateSelector are ignored for items already of the ItemsControl's container type RadWatermarkTextBox
    System.Windows.Data Error: 40 : BindingExpression path error: 'IsSearchActive' property not found on 'object' ''OpenFolderDialogViewModel' (HashCode=251973)'. BindingExpression:Path=IsSearchActive; DataItem='OpenFolderDialogViewModel' (HashCode=251973); target element is 'FileDialogSearchPane' (Name=''); target property is 'IsSearchViewActive' (type 'Boolean')

    At one point, I even hacked this code to specifically allow the root folder "F:" also just to see what would happen.  It did not fix the problem, it just made "F:" appear on the left (where I don't want it).

    So is there way to achieve what I want?

  2. Joe
    Joe avatar
    93 posts
    Member since:
    Nov 2017

    Posted 17 Jun Link to this post

    The more I try to work around this, the more I think that maybe this dialog is simply not intended to work the way I want it to.

    My goal was to completely hide the "This PC" item and show only my custom places on the left.  But the dialog really wants the "This PC" item in there:  It shows it even if I filter out every root drive on the machine.     It appears to be designed to show the path to my custom places when I click them, and apparently doesn't like it if I prevent that from happening.

    Clicking my custom places only enables the "Select Folder" button if I let it show the root paths to those custom places under "This PC".

    I was able to get mostly want by adding a DirectoryNavigating folder to go along with my DirectoryRequesting folder.   Now at least I can click on my custom places to get the "Select Folder" button enabled without allowing users to access undesired folders

    So unless I'm mistaken about how the dialog is supposed to work, I guess we can dispense with this question


  3. Dinko
    Admin
    Dinko avatar
    1183 posts

    Posted 19 Jun Link to this post

    Hello Joe,

    Thank you for the provided details.

    I am a little confused here regarding your scenario. In the code snippet, RadOpenFolderDialog is used. The filtering functionality is available for RadOpenFileDialog and RadSaveFileDialog dialogs, as stated in the Filtering help article. May I ask you to elaborate more on your scenario. What I am missing here?

    To leave only the Custom Places directories, you can hide the element holding the This PC. The element is FileBrowserTreeView. You can get it in the Loaded event of the dialog using our ChildrenOfType<T>() extension method and collapsed it. The following code snippet demonstrate this approach.

    private void RadOpenFolderDialog_Loaded1(object sender, RoutedEventArgs e)
    {
        var fileBrowserTreeView = (sender as RadOpenFolderDialog).ChildrenOfType<FileBrowserTreeView>().FirstOrDefault();
        if(fileBrowserTreeView != null)
        {
            fileBrowserTreeView.Visibility = Visibility.Collapsed;
        }
    }

    Regards,
    Dinko
    Progress Telerik

    Progress is here for your business, like always. Read more about the measures we are taking to ensure business continuity and help fight the COVID-19 pandemic.
    Our thoughts here at Progress are with those affected by the outbreak.
  4. Joe
    Joe avatar
    93 posts
    Member since:
    Nov 2017

    Posted 19 Jun in reply to Dinko Link to this post

    Hi Dinko,

    I am using RadOpenFolderDialog.  And I am using filtering with it.  The dialog has DirectoryNavigating and DirectoryRequesting events and I hook up event handlers to them.  My handlers are call and they do prevent the dialog from showing or navigating to those directories.  

    This makes sense to me because those two events are members of the DialogWindowBase class, from which RadOpenFolderDialog derives.

    It sounds like you are telling me that filtering is not supposed to work with RadOpenFolderDialog and if you say so I believe you, but I am here to tell you that it does work whether it's supposed to or not.  And I'm very happy about that because I need it.

    The bit about hiding the FileBrowserTreeView was great though, thank you for that
  5. Dinko
    Admin
    Dinko avatar
    1183 posts

    Posted 24 Jun Link to this post

    Hello Joe,

    Thank you for the additional details. Yes, the approach described in your post is a way to filter the folders inside RadOpenFolderDialog. I am happy to hear that it is working for you.

    If you have any other questions, you can open a new forum thread and we will be happy to help.

    Regards,
    Dinko
    Progress Telerik

    Progress is here for your business, like always. Read more about the measures we are taking to ensure business continuity and help fight the COVID-19 pandemic.
    Our thoughts here at Progress are with those affected by the outbreak.
Back to Top