I just updated an app to latest Juce (from late May) and now one of my views - a viewport/list in a scrolling menu thing comes up with some sort of default scrollbars. Both H and V are visible, at about the correct width, but the bars are expecting a smaller view - the bottom (H) scrollbar is halfway up. The view hasn’t redrawn properly to leave space for the bars either.
The view isn’t big enough to need scrolling even - the scrollbars don’t affect the view.
All subsequent views in the set work just right - it’s only the initial one.
Did something change in the order scrollbars get created? Or how they get attached to views, maybe?
Viewports have always been tricky though, because of the whole nasty feedback loop involved - i.e. when the content reaches a certain size, a scrollbar appears, which takes up a bit of space, which means the content has to resize again, which affects whether a scrollbar should be shown, etc. Over the years I’ve tweaked that algorithm many times!
I found some change where setting scrollbars visible was replaced by detecting whether they were visible.
But I’ve been stepping through. When I create my component, it gets resized about 10 times! By its own contents, by being put in another component, by that component being put in a window, by the window size being set, by the window doing an inset, etc.
It all seems fine, then at the last minute I think there’s some sort of ghost size or something, and the listbox/viewport makes some scrollbars based on that. Quite irritating. I’ve tried putting a few resized calls in my object’s structure (it’s a switching set of listboxes) but no dice yet.
Could there be some Component method I’m overriding but should be calling?
The odd thing is that certain window resizes (it’s a child component of a contained component of a resizable window, and expands height) will fix it, and some won’t. Haven’t found the pattern.
It’s continually updated 3-4 year old code, btw, worked perfectly through every other change, including JuceQuake :lol:
