Strange behaviour in StandaloneFilterWindow

Audio Plugins
1

Hi.

I have this strangest behavior when subclassing StandaloneFilterWindow:

I get this linkage error:

juce_StandaloneFilterWindow.obj : error LNK2019: unresolved external symbol "public: virtual class juce::PropertySet * __thiscall StandaloneFilterWindow::getGlobalSettings(void)" (?getGlobalSettings@StandaloneFilterWindow@@UAEPAVPropertySet@juce@@XZ) referenced in function __catch$??0StandaloneFilterWindow@@QAE@ABVString@juce@@ABVColour@2@@Z$02

The only time I use this class is here:

class StandAloneWindow : public StandaloneFilterWindow
{

public:
    StandAloneWindow(const String& title,
        const Colour& backgroundColour)
        :StandaloneFilterWindow(title, backgroundColour)
    {
    }

    virtual ~StandAloneWindow()
    {
    }

    virtual PropertySet* getGlobalSettings()
    {
        return CustomApplicationProperties::getInstance()->getUserSettings();
    }

private:
};

Thanks

2

Just looks like the build has got mixed-up to me - have you tried a clean rebuild?

3

Yea, I tried it, strange, I’ll keep searching.

Jules, The reason for removing the singleton is that you don’t want to have a global reference to an object?
What is the alternative ? dependency injection? I have some singletons in my project and I think about what to do with them.

Thanks

4

Singletons are just bad, and I’d rather not seem to be encouraging their use. If you have a shared object, the best way to manage it is to explicitly pass a pointer to it to any bits of code that need to access it, so that it’s not open for use/abuse by your whole codebase.

5

Hi,
Have you find infos about this error ?
I am experiencing the same one and cannot find a solution, or at least a reason !
Best regards

Edit : Jules, can you show an example of one test of this StandaloneFilterWindow please ?

6

Ok ! So it seems that I found the problem !
you’re calling the pure virtual function in constructor of the class…
At line 66 of juce_StandaloneFilterWindow, you do : PropertySet* const globalSettings = getGlobalSettings();
In those particular cases, it seems that function is not yet defined by our heritage and that makes linker crazy.
I double check this and come back to give more technical explication.

7

Ah, yes! Thanks, that class obviously needs rearranging a bit, I’ll get that sorted out.

8

So, what can be the solution for our issue ?

9

I’ll check something in later today.

10

For your concern, what I have done for now is :

  • declare an extern ApplicationProperties object
  • implement a virtual function getGlobalSettings() which returns userSettings() from ApplicationProperties
  • declare an ApplicationProperties object globally in my main file

This works as this, and I am fine with it.

Just a hint IMO :wink: