Possible Bug in TreeView


#1

Working on a treeview with multiselection and open/close enabled I found the following problem. It’s a bit of an edge case…! If a closed item has selected subitems and multi-selection with Shift is performed on the top level, the outcome is not as expected. That means some rows do not get selected between current and extended section.

The problem boils down to the selectBasedOnModifiers() method in juce_TreeView.cpp. In there the rows to select are determined by calling getRowNumberInTree() on the first and last item of the current selection. If a sub-item is selected, the returned rows are incorrect because getRowNumberInTree() always returns the parent row + the index of the subitem, regardless of the open/close status of the parent.

My current fix is to add this line to getRowNumberInTree() at line 1758:

        if (!parentItem->isOpen()) return parentItem->getRowNumberInTree();

now I’m not sure if that fix is great as getRowNumberInTree() is used elsewhere.

The whole problem can be reproduced in the JuceDemo XML/JSON demo by these steps:

  • Enable multiselection in jucedemo xml/json code, compile
  • Enter the xml below … argh the forum doesn’t like xml so I had to add spaces after <
  • Select item1 and all its subnodes in the treeview
  • Close item1
  • shift-click item6
  • item2 and item3 do not get selected as they should.
< tree>
    < item1>
       < subnode1/>
       < subnode2/>
       < subnode3/>
   < /item1>
   < item2/>
   < item3/>
   < item4/>
   < item5/>
< item6/>
< /tree>

#2

Bimpedibump?


#3

Thanks for reporting and for the suggested fix. I’ve added this to the develop branch.