TreeView::restoreOpennessState question

Have anyone tried the getOpennessState / restoreOpennessState functionality for FileTreeComponent ?
It is working but it restores only one level of the directories tree.
I mean that if I have for example “c:\aaa\bbbb\ccc\ddd” path fully opened in FileTreeComponent , then after saving component state with getOpennessState and restoring with restoreOpennessState I’m only getting the “aaa” directory opened and all the inner directories closed.

If after that, I’ll call restoreOpennessState one more time (after some delay and with the same parameter) - FileTreeComponent opens one more directory =)

As far as I got it looking through the code, the cause is somewhere in FileListTreeItem::itemOpennessChanged (bool isNowOpen) - that is called from restoreOpennessState .
New fdirectory data is just not ready for next restoreOpennessState iteration and the sate cannot be restored correctly, or something =)

I had this issue too. If i remember correctly, i used a timer to reapply the openesstate a few times. Please use forum search.

Thanks, but it seems that it is not the way how this code is supposed to work…

BTW, I’ve searched with restoreOpennessState keyword and it seems that I missed your posts somehow.

that is my solution in case if you interested: (see new code under // @dsa begin … // @dsa end )


[code] void itemOpennessChanged (bool isNowOpen)
if (isNowOpen)

        isDirectory = file.isDirectory();

        if (isDirectory)
            if (subContentsList == nullptr)
                jassert (parentContentsList != nullptr);

                DirectoryContentsList* const l = new DirectoryContentsList (parentContentsList->getFilter(), thread);
                l->setDirectory (file, true, true);

                // @dsa begin
                while (l->isStillLoading())
                // @dsa end

                setSubContentsList (l, true);

            changeListenerCallback (nullptr);


Jules, may be that could be checked in?

Thanks! I’ll have a look at that…

…sorry, but no! The whole reason that it uses the asynchronous directory scanning is so that you can open/close folders without locking-up the UI while it scans the contents. If I added your suggestion, it’d make all the background-scanning pointless!