Slider sub-class listener how to get sub-class object instead of Slider?

I have a Slider Sub Class (‘DualSlider’) with an added variable I need to access from the Slider listener, however the Slider* object it inherits from is passed to the listener instead of my sub-classed Slider, so the additional variable isn’t part of the received object.

I’m pretty stumped on how to implement a listener that receives my DualSlider* object instead. I have found a couple of examples of custom listeners but failed to get them working so far.

You can do :

DualSlider* ds = dynamic_cast<DualSlider*>(slider);
if (ds)
  // it's a DualSlider and now can use it via ds

But that kind of thing is considered bit of a code smell.

1 Like

You can make this a little more succinct:

if(auto* ds = dynamic_cast<DualSlider*>(slider)) 
  // it's a DualSlider and now can use it via ds

I’m curious as to why this is a code smell, and how can you avoid it otherwise in this instance?

It’s one of those things that if you get used to it, you might start using it a lot, making the code difficult to reason about, if every part in the code is doing those casts.

Of course in this situation it’s a convenient easy hack to use, as otherwise the Slider subclass would need to implement its own broadcaster/listener thing. (I suppose there might also be a few other options that could be used, though…)

1 Like

I’d say code smell as well… I’m not a fan of subclassing “heavy” classes like the Slider.

Are you aware that sliders can have one, two and even three “thumbs” (and values)?

You can easility create a “stereo” panner with one slider and a good LookAndFeel

I’m working with a ton of sliders stored in arrays and so this is about the ability to categorize them with identifiers for efficient filtering and updating the ValueTree in the listener. I’m currently using a sub string search on the name which is working well but that seems inefficient/hacky compared to having a purposed identifier. The sub-class is just about adding this category identifier.

I’d rather not use casting really, I was told years ago to avoid it as much as possible and always have tried. I thought there would be a simple way of adapting the listener, I thought sub-classing components would be pretty common?

Properties can’t help you here?

Is it possible to define custom properties?

I’m currently using the propertyName for filtering, but it’s that which requires searching for the common substring to get the category I need as they are named ‘CAT1,CAT2’ etc… so I’m searching for CAT so I know I’m dealing with a CAT.

This is needed for updating the ValueTree properties which has multiple sliders with min & max properties grouped under ‘CAT’ trees, so once I have the CAT I can assign the ValueTree properties directly.

The sliders referTo these values and initially I thought I’d be able to update directly using slider->getMinObject()->setValue(val), but even though after setting it & getting that value shows it is updated, it isn’t updated in the actual ValueTree so it seems like it’s a copy. That would have been the simplest solution I’ve found as it requires no filtering at all;

You can assign custom named properties to any juce Component, hence Sliders too.

It’s done via Component::getProperties(), which returns a NamedValueSet which is essentialy a dictionary where you can set and retrieve values by giving them a name.

So in your case you can give each of your Sliders that belong to the CAT category, a property named “category” which has value “CAT”, and use that for searching/filtering.

Is that what you may be looking for?

1 Like

that sounds exactly like the solution I’m looking for, I’ll look into it, thanks!

a belated thanks, this is really good to know and works perfectly!

1 Like