LookAndFeel issue with multiple plugin instances

We have a LookAndFeel_V4-derived class, which we declare using a std::unique_ptr, create using std::make_unique, and set as our plug-in’s default Look&Feel using setDefaultLookAndFeel in the Editor. This works fine for a single instance of the plugin.

However, whenever I create two instances of the plugin, cause any interaction that forces any of the Look&Feel functions to be used in that second instance, and then close the second instance of the plugin, the Look&Feel is gone in the first instance, and any redraw of a control reverts to using the original JUCE-style controls (sliders, buttons, etc.).

Looking at setDefaultLookAndFeel, I see it sets the Look&Feel using Desktop::getInstance.setDefaultLookAndFeel(). I’m not sure, but does that mean that this function is not intended to be used my plugins, which may have multiple instances?

Should I remove the call to setDefaultLookAndFeel(), and instead set it using just setLookAndFeel() at the Editor level, and let it propagate down through all its children, and their children?


Making that change fixes it. Perhaps the setDefaultLookAndFeel comments should specify that it’s not intended for plugins to use?

Where is your default LnF living? For it to be pointed by a singleton, it needs to be static -that is, stored in a SharedResourcePointer. Of course this is a problem if the LnF state can be different between instances -in that case, it can’t be a default LnF.

It’s a member of my Editor, not a shared object or singleton. Using the Editor’s setLookAndFeel instead fixes the problem.

Good. I was just pointing that setDefaultLookAndFeel is intended for plugins to use, but it’s a static method. There’s one default LnF per process.

1 Like