Help needed about different ways to build a new component

gui

#1

Hello everyone,

I’m trying to create a new Slider with the hability to handle synchronisation between two values.

Typically, I’m using a physical controller sending MIDI CC, and I’im switching between multiple identical layouts. My screen layout updates itself when refreshing, and is not necessarily synched with the controller’s knobs values.

The logical solution I thought about was to build a new component, derivated from Slider, implementing the synched state handling and using it as a condition to let it send messages or not (as long as you have not physically synched your knob with the slider, nothing is sent).

This part was easy, but I’m stopped by the painting part, as I would like to display the unsynched state.

I looked at the Slider code and the paint method relies on its internal pimpl::paint class, which is of course not available.

At that time, a solution would be to rebuild an evoluted slider from the main source, copying the whole original one and adding my features, of course. But I was wondering if I was missing something about a simpler and cleaner way to do this ?

Thank you very much for your help…


#2

Don’t derive a class from Slider, wrap a Slider instance in another class with your additional functionality.

You can also create your own graphics context from a previously constructed instance of Image and then paint onto that image for your “unsync’d” state and then paint that image in the paint method for the wrapper component.


#3

Thank you very much for your answer, Holy_City! I will try it that way.


#4

The Paint routines for the Slider can be easily overridden by implementing a Custom LookAndFeel for it. In the LookAndFeel you can draw anything you like.
Instead of subclassing or wrapping the Slider you could also use the Slider’s properties (Component::properties, namedvalueset) to store some custom values (your unsynced value) and pick those up when drawing the Slider. This is much simpler and does not require any subclassing.


#5

We have a BPM slider for instance that draws beatmarks on the Slider’s track. We have a custom LookAndFeel for BPM Sliders and we store the number of beats in the properties of the Component. When drawing the Slider we check if the number of beats is set in the Sliders’ properties and use that to determine where to draw the beat marks.


#6

Thank you Rebbur,

I think your answer is the easiest to implement in my case, as I already built a complete LookAndFeel I wanted to adapt to the synched / unsynched state.

It’s always funny to see how one can be looking at complicated solutions when you can overcome a problem a simple way…