EditorGUI and DocumentWindow behavior when the host loses focus

General JUCE discussion
1

Hi

I am making a vst and am confused by the difference in behavior between the EditorGUI and DocumentWindow when the DAW’s focus is lost.

How can I make the DocumentWindow appear the same as the EditorGUI?
I have tried getDesktopWindowStyleFlags on DocumentWindow but did not get good results.
I would like to get your ideas.

Thanks.

focus
focus1920×1080 224 KB

lost
lost1920×1080 220 KB

2

I simply destroy the Document Window in the editors destructor:

PluginEditorBase::~PluginEditorBase()
{
    if (paramWindow.getComponent())
        paramWindow.deleteAndZero();
}

If you care about the title bar, use TopLevelWindow instead of DocumentWindow.

1 Like
3

Thanks for the idea.
I tried it, but it seems that in the case I am having trouble with (clicking on the desktop or otherwise removing focus from the Host), the Editor destructor is not executed.

Furthermore, I tried to remove the focus from Host in the same way in other DAWs (reaper, Ableton Live), but the Editor screen remained visible instead of being hidden. I am increasingly confused.

In ableton Live, when I select a track and another track where I inserted a plug-in, only the Editor disappears in the same way it does in Cubase.

I wonder if there is a way to notify the moment when this Editor is hidden, which is different for each DAW…

4

If thats your goal Component::focusLost is what you are looking for.
Be sure that your component is also interested in keyboard focus with setWantsKeyboardFocus or grabKeyboardFocus etc

5

thank you.
I can’t override focusLost in the Editor, I don’t know if it’s JUCE itself or a bug, but it doesn’t work.

So far I have not found a solution.
I continue to welcome anyone with ideas.

6

When you say Editor do you mean AudioProcessorEditor. And what do you mean you can’t override it? Is it a compile time problem, or a runtime problem? I just added void focusLost (FocusChangeType x) override {} to my plugin and compiled no problem. I didn’t go as far to test if it got called at runtime.

1 Like
7

Focus is a problematic concept.
focusLost is called when the component loses KeyboardFocus. Only one Component has KeyboardFocus at a time. It doesn’t propagate to the parent or child. So it is never the whole window that has the focus.

There is a method Process::isForegroundProcess(), but that will return if the DAW is in the foreground, not if the plugin window is in the foreground.

Even the visibilityChanged() is to be dealt with caution: I am not sure if that is called, if a parent becomes visible or invisible. And I am not sure, if it means visibility in the Component hierarchy is changed, or if it is actually on the screen.

To be sure, if your editor is visible on the desktop, you have to check isShowing().
Worst case you need to check that in a Timer.

N.B.: it is a bad idea to open child windows from a plugin anyway, because the child window can get hidden behind the host window etc.

There are no guarantees about when an AudioProcessorEditor is destroyed or created, other than that there is always an AudioProcessor to it, i.e. the editor is destroyed before the processor.

1 Like
8

Thanks a lot for all the info.
As for the problem on Cubase, I solved it once by constantly monitoring Process::isForegroundProcess() with a timer.

As you said, using isVisible() and isShowing() didn’t work very well in the case where the DAW automatically shows a move to hide the ProcessorEditor screen.

I could not know what exactly is happening at the moment the DAW hides the ProcessorEditor screen (is it different for each DAW…?). I could not find out.

Thank you very much for this very useful information. I appreciate it.

9

Thanks for your input.
By Editor I mean ProcessorEditor.
I was able to override it after correcting my mistake. I was able to override it, but it was not called at the time I expected it to be.

I learned something. Thank you.