Bug report: Discrepancies in Multiple selection in ListBox


#1

Juce version: GIT clone, taken at October 5, 2010.
The bug is not platform-specific (checked under both Mac OSX [10.6.4] and WinXP [SP3])
Occurence: Juce Demo app (Table Components demo, Drag-n-Drop demo) where it uses an instances of multiple-selectable ListBox component.

The Description of the problem:
If the modifier key ==

  1. Command(Mac)/Control(Win), then the behaviour of selection process differs depending on the order in which rows are selected.
    If the firstly selected row has smaller index than the row selected after it, then the ListBox selects a contiguous range of rows instead of just two rows, which is wrong (i.e. it behaves as if the SHIFT modifier key was pressed). Albeit, if the temporal order of selection is reversed, that is, the larger index comes first, then everything works as expected.

If the modifier key ==
2) SHIFT then, on the surface, everything works (for the release build). But, if one runs the software under the debugger, then the SHIFT-selection, undertaken with smaller index coming first, hits jassert() somewhere in the guts of SparseSet::simplify() method. If the firstly selected row has larger index, then everything’s peachy.


#2

ok… well, thanks for the lovely detailed error report, but I can’t reproduce any of this!

I’ve tried exactly what you suggest, but it all seems just fine. E.g. in the demo, on the drag-and-drop page, I hold down command and click row 5, then 2, and it all works. Try it the other way round, it still works. Shift works fine with no assertions…

???


#3

I tried this too. Jules, try to:
-click row 2
-hold cmd and click row 5

It will act as if shift was pressed. But if you do the inverse (first 5 then 2) it will be right.


#4

Ok, I dug out the old 1.51 executable and tried that, and yes, that does seem to have a bug in it. But I fixed it a looong time ago - the tip version is absolutely fine. capyTan, you say you’re using the latest version from GIT, but I think you may be mistaken!


#5

No, I used the latest version from GIT, but I just took the Juce Demo from the ‘prebuilt’ folder, the contents of which, as it turns out, doesn’t necessarily reflect the latest changes. I assumed it does.
Thanks for clarifications!


#6

Ah! I see. I can’t keep all the binaries updated because that’d make the repository humungous, so they generally only get updated when I do a release.