Is it impossible to know when your plugin is brought to the front or gains focus?

[stephenk]

@reuk

Override focusOfChildComponentChanged on your plugin editor

The problem with this (correct me if I’m wrong), is that when your plugin window is brought to the front (I’m testing in the JUCE AudioPluginHost), the currentFocusedComponent is set to NULL. You can see that using a focusChangeListener.

Unlike a JUCE GUI App, where when the MainWIndow of your app (a DocumentWindow) is brought to the front, all sorts of stuff is done to restore the focus to what was the last focused component.

I’m working on both types of projects from a single source base, but my standalone app is a real JUCE GUI app, and not my plugin wrapped in a standalone. So I was looking to make the behavior a little more consistent between the two.

My use case was (going to be) trying to determine when the plugin window came to the front, so that I could target the next tab key press at a specific component, rather than having to have the user click inside the content in order to make tabbing work.

I’m not sure focusOfChildComponentChanged() would be of any use for this…

EDIT: BTW, please see this for a related request:

[FR] Ability to disable restoring of focus on bringToFront in GUI Apps

it’s fine and wonderful that JUCE GUI Apps do all sorts of stuff in ComponentPeer to restore the focus of a window to the last previously focused component, when a TopLevelWindow (DocumentWindow) is brought to the front (say by resuming your app from another one), or when you switch between multiple document windows. but what if you would like to disable that behavior? I discovered, after a deep dive into it, that it’s almost impossible to override this in any effective way. What is really need…