LookAndFeel issue with multiple plugin instances

Audio Plugins
#1

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?

2 Likes
#2

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

#3

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.

Isn't it a bad practice to call setDefaultLookAndFeel()?
#4

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

#5

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