In a few instances on a couple of projects I’ve been creating odd, one off controls that have their own dedicated LookAndFeel:
class VolumeKnob : public Slider, ...
{
class VolumeKnobLAF : public LookAndFeel_v3 {...};
VolumeKnobLAF laf;
explicit VolumeKnob (...) : Slider(...)
{
setLookAndFeel(&laf);
}
resized() { laf.resized();}
}
I realise this is not the core intent of LookAndFeel, but it has an advantage (besides convenience) which is the ability to cache paths, gradients and bounds on resize() in order to optimise paint().
In a recent JUCE update I’m getting asserts when the UI is shutting down because the destruction order is such that the Slider’s child LookAndFeel is being deleted before the slider that owns it.
I could throw a setLookAndFeel(&LookAndFeel::getDefaultLookAndFeel());
in the destructor of VolumeKnob. But I feel that I may be missing a neater more obvious solution.
Anyone got any suggestions or constructive critisim?
Thanks all,
Dave