Some JUCE apps don't get keyboard focus on start-up

Windows
1

Hi,

Some JUCE applications don’t get keyboard focus on start-up. When double-clicking in explorer, the JUCE window will pop up behind the explorer window, and the taskbar icon will flash, but the window will not be focused. This is reproducible with the JUCE demo, but not with ProJucer.

It can be reproduced with the Hello World example by modifying the constructor of the HelloWorldWindow as follows:

// And show it!
setUsingNativeTitleBar(true);
setResizable(true, true);
setVisible(true);

It will no longer happen if you change the order:

// And show it!
setUsingNativeTitleBar(true);
setVisible(true);
setResizable(true, true);  // ← move down

But this will cause the window to appear twice (which gives a very noticeable stutter in the “fade in” animation, if you have those enabled).

Finally, this order works as expected

// And show it!
setResizable(true, true);  // ← move up
setUsingNativeTitleBar(true);
setVisible(true);

With the Demo app, moving those calls in that order in MainAppWindow::MainAppWindow() solves the problem. As to why, I have no idea. Anyone knows what’s happening here?

–
Roeland

1 Like
2

setUsingNativeTitleBar will actually cause the Window to be recreated. Best to do that call before all other calls on the Window.

3

Also, in Xcode and VS2015, running a juce application in the debugger will sometimes not focus the app correctly on launch. Try launching it by hand and see if the problem goes away.

4

I’m double-clicking the executable in Windows explorer.

5

We were having trouble with accessibility clients being pretty much useless on Windows because our window was being created in the background. We tried calling grabKeyboardFocus() in a bunch of different places but nothing was working.

The solution proposed here to move the call to setResizable() above the call to setUsingNativeTitleBar() has fixed this bug for us! We still need to also call grabKeyboardFocus() on the component we want to be initially focused, but those two things together have made the app useable by accessibility clients on Windows now!

1 Like
6

I think is actually caused by a bug in juce::ResizableWindow::setResizable… It’s often a red flag when the order in which setters are called in a constructor has an effect of the resultant state.

In juce::TopLevelWindow::setUsingNativeTitleBar, a juce::FocusRestorer is used to make sure focus is regained after the window is recreated:

However, when the window is recreated in juce::ResizableWindow::setResizable, the focus isn’t restored:

1 Like