Viewport suggestion



void Viewport::parentSizeChanged()

Otherwise the Scrollbars aren’t repainted correctly when the parent is resized.





No… That doesn’t make any sense. The parent’s size is irrelevant to whether or not scrollbars are shown.



No… That doesn’t make any sense. The parent’s size is irrelevant to whether or not scrollbars are shown.[/quote]

Not shown… repainted or resized

What I found was that when I would resize the parent plugin window (RTAS) that the horizontal scrollbar wouldn’t repaint correctly without a call to updateVisibleArea().



Here’s a video…




In your video it looks like you’re inheriting from a Viewport class. That’s a bad idea, and perhaps you’re breaking it by overriding one of the methods that it relies on? e.g. are you overriding its resized() method and blocking the base class method?


Bingo… sorry I thought I was calling the base class… dammit… :oops:

I had to subclass Viewport to fix a bug I see in other JUCE based apps as well… if you have a horizontal scrollbar and scroll right then close and reopen the plugin the thumb always jumps to the left… I fixed that by subclassing Viewport and adding a setScrollBarRangeStart() method

void CMainViewport::scrollBarMoved (ScrollBar* scrollBarThatHasMoved, double newRangeStart)
    if (m_pProcessor)
        m_pProcessor->m_PlayerInfo.fMixerScrollPos = newRangeStart;
    Viewport::scrollBarMoved (scrollBarThatHasMoved, newRangeStart);

void CMainViewport::setScrollBarRangeStart(double newRangeStart)
    ScrollBar* pscrollbar = getHorizontalScrollBar();

These are now the only methods in the CMainViewport class.




Perhaps a suggestion for Jucer to always have a call to the base class for resized() so that I don’t forget to check the Jucer generated methods :?




It only stamps out some templated code, it’s not smart enough to understand the details of any base class that you might choose to give it, or to know which of them require that kind of special treatment.