interpret not returning AudioProcessorEditor pointer

[adamski]

I have the following code:

juce::AudioProcessorEditor* MyAudioProcessor::createEditor()
{
    auto view = jive::parseXML (layoutXml);
    DBG ("Parsed layout XML: " << view.toXmlString()); 

    // interpret() needs a juce::AudioProcessor* when interpreting "Editor"
    // types in order to construct the juce::AudioProcessorEditor
    if (auto editor = viewInterpreter.interpret (view, this))
    {
        jassert (editor != nullptr);
        // When interpreting an "Editor" type, the top-level item will be a
        // jive::GuiItem AND a juce::AudioProcessorEditor. So we can do a
        // dynamic-cast here to check that the editor was created successfully.
        if (dynamic_cast<juce::AudioProcessorEditor*> (editor.get()))
        {
            viewInterpreter.listenTo (*editor);

            // Release ownership to the caller.
            return dynamic_cast<juce::AudioProcessorEditor*> (editor.release());
        }
    }

    // Fallback in case the editor wasn't constructed for some reason
    return new juce::GenericAudioProcessorEditor { *this };

}

The dynamic cast fails; the type seems to be GuiItem only.

[adamski]

Looks like I need to define JIVE_IS_PLUGIN_PROJECT=1 - this should be in the docs!

[adamski]

Is there not a way to automatically detect if we're in a plugin project with JUCE?

[ImJimmi]

Looks like I need to define JIVE_IS_PLUGIN_PROJECT=1 - this should be in the docs!

Ahh appologies - I thought I'd written that somewhere! Glad you found the solution though

Is there not a way to automatically detect if we're in a plugin project with JUCE?

We could maybe default JIVE_IS_PLUGIN_PROJECT to check for JucePlugin_Name, or one of the other standard definitions. I'm not 100% sure they're guarenteed to be defined though

[ImJimmi]

Looks like JUCE does define a whole bunch of macros (in CMake at least - I assume Projucer sets the same ones):

https://github.com/juce-framework/JUCE/blob/51d11a2be6d5c97ccf12b4e5e827006e19f0555a/extras/Build/CMake/JUCEUtils.cmake#L1544

So we could do something like

#ifndef JIVE_IS_PLUGIN_PROJECT
  #ifdef JucePlugin_PluginCode
    #define JIVE_IS_PLUGIN_PROJECT 1
  #endif
#endif

[adamski]

Looks like JUCE does define a whole bunch of macros (in CMake at least - I assume Projucer sets the same ones):

https://github.com/juce-framework/JUCE/blob/51d11a2be6d5c97ccf12b4e5e827006e19f0555a/extras/Build/CMake/JUCEUtils.cmake#L1544

So we could do something like

#ifndef JIVE_IS_PLUGIN_PROJECT
  #ifdef JucePlugin_PluginCode
    #define JIVE_IS_PLUGIN_PROJECT 1
  #endif
#endif

I think that makes sense, although I would probably just check the JucePlugin without needing another definition. However there might be situations where an explicit definition is useful.