FileBrowserComponent keep tree state between refresh?

General JUCE discussion
1

Hi,

Is there a simple way to keep the state of the FileBrowserComponent between refresh ? open/closed node and selected file ?

I use a FileBrowser to drag & drop file in a directory (and also to delete file) and when I refresh the component I would like to see the FileBrowser in the same  state it was before my actions.

 

I tried to use the method "setFileName" to select a file (it could be nice to be able to select an array a file) and atleast open a subdirectory but no node is open in the Treeview.

2

If you can get the FileTreeComponent, then that's a TreeView, so its openness can be saved/restored like any other tree.

3

Ok,

I got the FileTreeComponent and use getOpennessState and restoreOpennessState to try and restore my FileBrowserComponent tree state.

But also I can see that the tree is restore to its previous state (breakpoint in TreeViewItem::restoreOpennessState) when the FileBrowserComponent is display, the tree state is the one by default (all node closed and no selected item).

 

Here is the code I use:

    FileTreeComponent* pTreeComponent = static_cast<FileTreeComponent*> (mPresetBrowserComp->getDisplayComponent());

    ScopedPointer<XmlElement> pTreeState = pTreeComponent->getOpennessState(true);

    mPresetBrowserComp->refresh();

    //pTreeComponent->setDefaultOpenness(true);

    pTreeComponent->restoreOpennessState(*pTreeState, true);

If I replace restoreOpennessState by setDefaultOpenness then all the node are in open state.

If there something I am missing ?

4

Any comment on my previous post and the code I use ?

5

Really not sure, sorry - would require more debugging time than we can spare right now to see what's going on..

6

Hi Jules,

The problem must come from the fact that in TreeViewItem::restoreOpennessState(), subItems is always empty on subdirectories.


subItems should then be filled before calling this method, shouldn't it?

 

void TreeViewItem::restoreOpennessState (const XmlElement& e)
{
   if (e.hasTagName ("CLOSED"))
    {
        setOpen (false);
    }
    else if (e.hasTagName ("OPEN"))
    {
        setOpen (true);

        Array<TreeViewItem*> items;
        items.addArray (subItems);

        forEachXmlChildElement (e, n)
        {
            const String id (n->getStringAttribute ("id"));

            for (int i = 0; i < items.size(); ++i)
            {
                TreeViewItem* const ti = items.getUnchecked(i);

                if (ti->getUniqueName() == id)
                {
                    ti->restoreOpennessState (*n);
                    items.remove (i);
                    break;
                }
            }
        }

        for (int i = 0; i < items.size(); ++i)
            items.getUnchecked(i)->restoreToDefaultOpenness();
    }
}

 

7

The subitems can't possibly all be created for closed items, because that could involve scanning the entire filesystem..

8

Search for "hack of the month" (incl the quotes) and you might find what you're looking for!

9

The issue is not about creating subitems for all closed items.

It is about the recursivity of "restoreOpennessState" not working because the subitems is allways empty?

 

If you want to restore the state of a tree where 3 child folder are open, you have to call "restoreOpennessState" 3 times.

 

The "hack of the month" would work fine to open one branch but to restore a tree complete state not so much ...
 

10

Can't you just add the dropped file "manually" to the filetree view instead of refreshing the filetree?

11

Yes I think I could update just the treeitems with the files I add or remove. But I don't know what kind of issue that could create with the FileBrowserComponent containing said treeitems and what would happen when I use the FileBrowserComponent methods afterward.