'ScrollBar' uses 'private' to inherit from 'AsyncUpdater'

Another one. Sorry for all the questions on a Sunday, an unfortunate side-effect of my being a weekend warrior :slight_smile:

Because the scrollbars in Viewport always appear next to it, and in my program I wanted scrollbars that are not immediately next to the viewport they relate to, I hid the viewport scrollbars, and instantiated two scrollbars of my own in the viewport’s containing component, copying the scrollbar functionality from within viewport to make them work the same way.

That worked fine for me until I update to the latest Modules branch yesterday, where now I get the below error:

error C2247: ‘juce::AsyncUpdater::cancelPendingUpdate’ not accessible because ‘juce::ScrollBar’ uses ‘private’ to inherit from ‘juce::AsyncUpdater’

This relates to the two lines of code below, repeated for H & V scrollbars inside Viewport’s updateVisibleArea function, and inside my own updateVisibleArea that I copied to:


Now to my question:

How come viewport gets to make those calls to those scrollbar methods, and my code doesn’t?


Well, viewport is a friend class. But looking at it again, I don’t like the way I wrote that… I think I’ll remove the friend relationship and make the AsyncUpdater a public base (which would also solve your problem).

The “correct” thing to do would actually be to keep the base class private (because it’s an implementation detail, and really shouldn’t be used by other classes), but to add a couple of public methods to Scrollbar that provide the functionality that you and the the Viewport needs, but which have more meaningful names. But TBH in this case I can’t really think of any better names than you’d get by just exposing the base class…

Sorry, I realized my question was ambiguous:

This is not a request to make those methods accessible to Juce end users necessarily;

Rather, I don’t understand technically what is different between Viewport accessing those methods in scrollbar, and my own class, largely a straight-up copy of viewport, not being able to.

So I’m asking primarily to learn rather than as a feature request.

…And now we were typing at the same time :slight_smile:

Ok, it’s a friend class, that makes sense!

I can work around it regardless, so the change is not necessary to me, but when I saw it it made me wonder.

Thank you!

I’ve made that change now.

It’s an interesting question. One of the trickiest parts of doing a library is keeping the balance right between exposing too much or too little of the way classes work.