There is a problem with re-activating the app after it has been minimized. Re-activating by clicking on the app icon on the dock shows a problem, whereas re-activating by using cmd-tab doesn’t show the problem.
Here is what I do to show the problem…
Selecting minimized app using the doc causes the problem:
… start my app (document-based, FWIW)
… minimize the app by clicking on minimize button in window title bar
… select different mac application
… click on my app icon on the doc, my app menu appears at the top
… the bad news is that all sub-menu items are greyed-out apart from “Quit” (and the one sub-menu pop-up that I “manually” added myself)…! i.e. file New etc. are not available.
Selecting minimized app using cmd-tab does not show the problem:
… start my app
… minimize the app
… select different application
… use cmd-tab to re-select my application [note that this is INSTEAD of clicking on my app icon on the doc!!], my app menu appears at the top
… all is OK with menu items e.g. under File
… note tha that if I’d previously restored using the dock, it’d still have the menu items greyed-out and I’d first have to restore the app window for the cmd-tab mechanism to work OK.
The reason this is a pain is that our users want the app minimized but with basic functionality still available to control it via the menu. They seem to be used to re-activiating an app by clicking its icon on the dock, rather than cmd-tabbing to it…!
Sounds like it’s a focus problem. If the commands in the menu use the ApplicationCommandTarget stuff, then if the window is restored without gaining focus, none of the targets will be found, and it’ll get greyed-out.
I’ve not tried it, but maybe a grabFocus call in response to the kEventWindowExpanded message might kick it into life?
Actually, thinking about it just clicking on the dock won’t result in emission of a kEventWindowExpanded event… I double-checked this with the debugger, too.
With debugger, clicking on the icon down on the dock when minimized, the event I get is…
kEventAppFrontSwitched
At the moment, you call this:
juce_HandleProcessFocusChange
Which doesn’t do anything as currentlyFocusedPeer is NULL.
So, I modified it to look like this:
void juce_HandleProcessFocusChange()
{
keysCurrentlyDown.clear();
if (currentlyFocusedPeer == NULL)
{
// Try to handle if dock icon clicked-on when app minimized ...
// ensure that the sub-menu items are not-greyed out!
for (int i = Desktop::getInstance().getNumComponents(); --i >= 0;)
{
Component* const c = Desktop::getInstance().getComponent (i);
if (c != 0)
{
ComponentPeer *cp = c->getPeer();
if (cp != NULL)
{
cp->grabFocus();
//c->repaint();
}
}
}
}
else if (HIViewComponentPeer::isValidPeer (currentlyFocusedPeer))
{
if (Process::isForegroundProcess())
currentlyFocusedPeer->handleFocusGain();
else
currentlyFocusedPeer->handleFocusLoss();
}
}
But the long and short is that this still leaves the menu sub-items all greyed out. Bah, humbug!
Hoping you have some more ideas.
I wonder if you need a handler for kEventCommandUpdateStatus, or some such…? Maybe kEventMenuEnableItems …? Sorry, not really sure, as I’m getting lost in the Juce code…!
On a separate note, I see this…kHICommandPreferences … and kHICommandAbout … which we could maybe use to hook-in a standard way of showing Preferences/About dialog under Juce on Mac?
Hmm - I just had a quick go with the jucer, but that seems to get the focus back ok when it’s un-minimised. I wonder if it’s something else that’s causing this…?
Must be related to focus - when the window is re-maximised it’ll try to find a comp to take the focus, so maybe its not finding anything suitable. Or maybe the top-level comp is getting focus, and not the content comp… I’ll have a think.
I’ve been trying to compare my app code to what goes on the Jucer, and the only obvious difference that springs to mind is these few lines in the jucer_MainWindow.cpp file… might I ask what they do / if they’re significant?
// use a temporary one of these to harvest its commands..
JucerDocumentHolder tempDesignHolder (ObjectTypes::createNewDocument (0));
commandManager->registerAllCommandsForTarget (&tempDesignHolder);
Joining the conversation a decade late, but I figured this was better than starting a new topic.
In short, I’m having the same issue - switching back to my standalone app means it has no focus and so menu bar is greyed out until I click on it twice.
What is the best way for me to recognise that I have clicked the app icon in the dock (on Mac) and so my app needs to take focus again?
Thanks!
Adam
UPDATE: I have tried inheriting from FocusChangeListener in my top level component and that deals with some of the issues (e.g. coming back from minimisation) but not others. Particularly sometimes I can navigate back to my app using cmd-tab on Mac but the menu bar can still sometimes be greyed out
