One off LookAndFeel classes and destruction order

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

For me this works:

  • If the LookAndFeel instance is owned by a parent (so guaranteed to outlive the component that uses it), nothing has to be done
  • If the class itself owns the LookAndFeel (usually true for the top level component), setting nullptr as LookAndFeel is perfectly fine.

There are guards for the lookAndFeel != nullptr, and the getLookAndFeel() always provides the fallback.

2 Likes

How about:

~VolumeKnob()
{
setLookAndFeel(nullptr);
}

Matt

1 Like