Presently, it is impossible the know when your plugin window is brought to the front. There is no notification that reliably can give you this information, or from which it can be reliably deduced. I have reported on this substantially here:
In an app, you have TopLevelWindow::activeWindowStatusChanged(), and Component::broughtToFront() (for the window), and the windows themselves gain and lose focus - there are multiple ways to determine if a window has come to the front.
In a plugin, nothing.
One may wish to direct focus to a certain component, or reset certain parameters, or clear memory, or… whatever. Honestly, I don’t even believe that some sort of compelling use case is required to justify this request. It should just be in there - of course you would want to know when the plugin window is in front, somehow. It would have many possible applications. Thank you!
If a plugin is qwerty keyboard-centric rather than fully mouse driven, and users have familiarity with that, this is quite an important feature to make the keyboard entry instantly available as soon as the plugin window gets focus and having that detection present.
A simple use-case is having a preset browser that supports arrow key navigation, which is quite useful. If the plugin window is closed and reopened and it retains last shown (preset browser), but the arrow keys are non-functional until the plugin is clicked onto, it doesn’t flow well. The user almost expects to be able to use the keyboard straight away and it leads to “why did it work then but not now” confusion.
More elaborate functionality like F-keys going to sections of the plugin or keys navigating a central table/listbox/come step editor fails similarly because the opened window does not allow immediate keyboard focus because it cannot detect when the window has received focus.
I observed Renoise Redux, a non-Juce plugin that is qwerty keyboard-centric being a tracker, and it immediately takes the keyboard focus to the tracker part as soon as the window is focused. It needs this flow since the user expects a keyboard-first/mouse-second operating approach to the plugin.
So being able to detect a window focused/brought to front event would be a good feature for these reasons and leave it to the developer to decide what to do. Currently it works fine for mouse-first plugins where you are almost guaranteed a click before any keyboard entry, but not for keyboard-first led plugins.
Have you tried with the FocusChangeListener? I use it in my custom ComboBox component to determine whether a click occurs outside my plugin’s window.
