How to Properly Clear LookAndFeel References?


#1

Hi I am dealing with an issue where a custom LookAndFeel class I use in a plugin triggers a breakpoint when opening an the plugin editor.

LookAndFeel::~LookAndFeel()
{
/* This assertion is triggered if you try to delete a LookAndFeel object while it’s
- still being used as the default LookAndFeel; or
- is set as a Component’s current lookandfeel; or
- pointed to by a WeakReference somewhere else in the code

   Deleting a LookAndFeel is unlikely to cause a crash since most things will use a
   safe WeakReference to it, but it could cause some unexpected graphical behaviour,
   so it's advisable to clear up any references before destroying them!
*/
jassert (masterReference.getNumActiveWeakReferences() == 0
          || (masterReference.getNumActiveWeakReferences() == 1
               && this == &getDefaultLookAndFeel()));

}

Clearly the reference to the LookAndFeel class which I am giving my sliders needs to be cleared somehow in the destructor. I solved this issue by adding:

mySlider.setLookAndFeel(&LookAndFeel::getDefaultLookAndFeel());

To the AudioProcessorEditor destructor, but this seems kind of hacky. What is the best practice way to do this? I am passing the look in feel reference to my sliders as described in the JUCE tutorial here:

mySlider.setLookAndFeel (&myCustomLookAndFeel);


#2
mySlider.setLookAndFeel (nullptr);

#3

So do that in the destructor of AudioProcessorEditor?

That still strikes me as a little weird (a bit too similar to having to use delete or something). If that works though I’ll certainly take it, just want to make sure I’m keeping to best practice as much as possible.


#4

You can also avoid a lot of these problems by declaring the LookAndFeel object before you declare any of the components that use that object. This means the components will be destroyed before the LookAndFeel is destroyed.


LookAndFeel assert firing on 5.2 quit
#5

Thanks so much. Very good to know. This is the type of solution I was looking for.