Bug: regression in TreeView::restoreOpennessState


In JUCE 6.1.5 TreeView::restoreOpennessState() behaves differently than in JUCE 6.0.7.

I am using TreeView::restoreOpennessState() to restore both the openness and the scroll position. The openness is restoring fine. But in JUCE 6.1.5 the scroll position only restores correctly, if the tree was already open. Whereas in JUCE 6.0.7 it would also work correctly, if the tree was closed.

I have attached an example project, which you can use to reproduce the problem. Its a modified version of the JUCE “ValueTreesDemo”. See attached file “Test_restoreOpennessState.zip”.

Here is how to observe the problem:
When you run the attached project, a JUCE tree view appears. Scroll down a bit and click on “Save Openness”:

Scroll up again and close the topmost node, to hide the rest of the tree:

Now click on “Restore Openness”. You are going to see, that the openness restores. BUT: The scroll position is at the top. I.e. the scroll positions is not restored.

Now click once again on “Restore Openness”. With the second click, the scroll position IS restored.

In other words: TreeView::restoreOpennessState() has to be called twice, in order for the scroll position to be restored. If the tree was closed to begin with.

If you try the same with JUCE 6.0.7, you are going to see, that it works fine and it restores both openness AND scroll position with the first click on the “Restore Openness” button. I.e. it is not necessary to call TreeView::restoreOpennessState() twice.

I also tested with the develop branch from to weeks ago (April 28th). I get the same problem there.

I assume this regression was introduced when overhauling the TreeView classes some time ago?

I am running JUCE develop on an Intel Mac with macOS 11.6.2.

Here is the project to reproduce the problem with:
Test_restoreOpennessState.zip (13.1 KB)

This issue has now been fixed on develop

Thanks for fixing!