Viewport Request

Hi Jules

Would you consider adding setViewPosition (const Point< int > &newPosition, bool notifyScrollbarListeners) or scrollToANewPosition(const Point< int > &newPosition)?


What would be the purpose of those?

I need the listeners of the viewport’s scrollbars to be triggered also in setViewPosition()

Ok… but if the scrollbars move, then their listeners will already be triggered, right?

And if you want your listener to be triggered even when a scrollbar doesn’t move, then it shouldn’t be a scrollbar listener at all, it should be listening to any movement of the view component.

No, that’s the problem, setViewPosition() moves the scrollbars but does not trigger the listeners.

But it calls Scrollbar::setCurrentRange, which will certainly trigger a callback if the value changes… Are you sure?

I remember a problem in the Juce demo from a long time ago. After resizing a list when the scrollbar was in a certain position, the thumb would not disable even though all the elements were in view. Debugging the complex interaction of notifications when attributes of the system changed was really mind-bending. I never did fully understand it.

I tried it with 2 different viewports in my app.

setCurrentRange() does get called and in turn calls triggerAsyncUpdate().
But for some reason the ScrollBar::handleAsyncUpdate() that triggers the callback does not get called.

AFAICT the code is fine, but if you can point out something that’s failing, then let me know.

Maybe it’s the cancelPendingUpdate() inside updateVisibleArea()

    if (vBarVisible)
        verticalScrollBar.setBounds (contentArea.getWidth(), 0, scrollbarWidth, contentArea.getHeight());
        verticalScrollBar.setRangeLimits (0.0, contentBounds.getHeight());
        verticalScrollBar.setCurrentRange (visibleOrigin.y, contentArea.getHeight());
        verticalScrollBar.setSingleStepSize (singleStepY);

Maybe when you wrote the last two lines in updateVisibleArea()


You meant to delay calling the scrollbar’s listeners but you actually canceled them using cancelPendingUpdate()?

Ah, well, I clearly didn’t want that event to fire. The viewport code can be very fragile with feedback loops, so I wouldn’t want to change that, it’d be almost certain to break something in a very subtle way!

Ahh…that is exactly what I meant. Is there any way to simplify it?

Ahh…that is exactly what I meant. Is there any way to simplify it?[/quote]

It’s probably one of the bits of code that I’ve rewritten the most times, and have never quite managed to rationalise it as much as I’d like to. For something that seems so straightforward there are a huge number of edge cases.