How to use Pimpl from Slider inherited class?

Hello,
maybe the subject is too generally and not clear. But more detailed explanation is:

I have AudioProcessorParameter attached to ‘MySlider mySlider’ through SliderAttachement pointer.

But in MySlider I have overrided mouseDown(), mouseUp(), mouseWheelMove(), and other mouse concern methods.

So AudioProcessorParameter::Listener::parameterGestureChanged() is never called.

I’ve found out that in oryginal mouseDown(), mouseUp(), mouseWheelMove() etc it is solved by some private member named Pimpl.

So my question is how to solve it by my own in my overrided mouse methods?

Of course in each overrided mouse method I can call oryginal methodl, for example:

void mouseWheelMove(const  MouseEvent &e, const MouseWheelDetails &wheel) override
{
    Slider::mouseWheelMove(e, wheel);
    // and here my own code
}

But I feel like it is not proper way. I just want to send message to AudioProcessorParameter::Listener. And all other things from original Slider::mouseWheelMove() I don’t want to use.
That’s why I wonder how I solve that with my own code. But as I told the pimpl member of Slider is private. And I also don’t have access to such classes like DragInProgress which is responsible for calling slider attachements.

I’m afraid the answer is not what you like to hear: The Slider class is not intended to be inherited, and especially not to be customised by overriding the ouse events.

An alternative is to add a MouseListeer to the Slider, that way you get additional callbacks to the original ones.

What is your use case, that you want to inherit Slider?

Hello Daniel,
thanks for your reply.

The case, that I want to inherit Slider is I want other behaviour of knobs and sliders in my plugin. I also want those knobs to be remote from other parts of GUI. For example I want to be able to set threshold in conpressor on the compressor graph, but then I need to update the knob also.
I also want to change the graph when I dragging knob. Of course I could do that in in Slider listener when value is change. But still I want my slider knows about some variables from graph.

Some other knobs I want to block at some value, and want to make possible to pass that value only when “Alt” button is pushed.

I also want to have my custom text editor for each knob to change value by changing text in editor.

Things like that. There are more causes I want to inherit from Slider. Now I don’t remember all.
I am sure all of that I can solve in other way. But if Slider has a lot of virtual methods, so I thought it’s OK practice to inherit from it.

Actually I solve my issue by calling original mouse methods in overriden methods. And it works. but I didn’t make too much tests. So I am not sure if it’s good solution. And that’s why I ask for your help.

For the use case to have the compressor graph changing the value, I would make the compressor graph a completely separate control, but connect it to the same parameter. You can create a ParameterAttachment for your compressor graph to keep it synchronised. Since JUCE6 it can also inherit the ParameterAttachmentBase, before you woud have to write it from scratch.

The additional benefit of that solution is, you can later decide the UI, if you want to display the knob, the graph or both without changing the components.

The modifier is indeed something that is hard without overriding and calling the original methods like you did.

Hello, great. It’s really interesting in the future I will consider to use such solution.

But now for me I imagine it’s to much changes, I have about 30 sliders in my project, each one has different functionality. To change all of that it will cause many problems I suppose.

So it sounds for me like big update for my plugin.
But now everything works perfect for me, just one functionality I need, to call AudioProcessorParameter::Listener::parameterGestureChanged()

That’s all. So at the moment I leave it like it is (I mean calling original Slider mouse methods in each overriden method), or use some smarter solution if somebody here advice me it.
And your solution I need to consider in the future. It sounds really good. Maybe I even could make my graph to be Slider with some sophisticated look and feel. But it’s all the future.

(Don’t say that loud, someone will make it final)

4 Likes

(“the FINAL countdown” starts playing in background…)

3 Likes

If they make it final I’m going to throw my computer out of the window, then I’ll finally start my new career as a farmer.

5 Likes

IIRC it was suggested at some point, but there is probably a lot existing code that would break…

I’m in with the farmer idea :smile:

1 Like

@daniel I’m confused—the documentation implies that inheriting is intended.

/**
A slider control for changing a value.

The slider can be horizontal, vertical, or rotary, and can optionally have
a text-box inside it to show an editable display of the current value.

To use it, create a Slider object and use the setSliderStyle() method
to set up the type you want. To set up the text-entry box, use setTextBoxStyle().

To define the values that it can be set to, see the setRange() and setValue() methods.

There are also lots of custom tweaks you can do by subclassing and overriding
some of the virtual methods, such as changing the scaling, changing the format of
the text display, custom ways of limiting the values, etc.

You can register Slider::Listener objects with a slider, and they'll be called when
the value changes.

@see Slider::Listener

@tags{GUI} */
4 Likes

Indeed, thinking about it I found more examples that require to inherit from Slider.
From an architectural point of view I would still try to avaoid it as much as possible, but some customisations are not possible without.