Re: Making menu bar application's window key
Re: Making menu bar application's window key
- Subject: Re: Making menu bar application's window key
- From: Daniel Jalkut <email@hidden>
- Date: Sat, 05 Nov 2005 19:33:43 -0500
If you look carefully at the situation being discussed, you'll see
that both Justin and my apps are faceless background applications
presenting a UI via a menu bar status item. So the consequences of
"becoming frontmost" are much less severe than they would be for a
regular application. In Justin's app, the keyboard invocation brings
the user to a very specific state of modally browsing a drop-down
window.
I would agree however that if there's a convenient way to get key
focus without becoming frontmost momentarily, that would be
preferable. Does anybody know how to do it?
Daniel
On Nov 5, 2005, at 7:28 PM, John Stiles wrote:
This is considered "impolite" from a human interface perspective.
Forcing your app frontmost is not friendly. Instead, bounce the
dock icon (once or repeatedly, depending on the urgency) and
display your message when you become frontmost.
Daniel Jalkut wrote:
Hi Justin. I face a similar situation in FastScripts: putting up
UI is not sufficient for gaining "frontmost" status.
What I do is very carefully acquire frontmost status and then give
it back when I'm done. Since for your app it seems like you need
it every time the user invokes the "menu" item, it shouldn't be
too complicated. In FastScripts since I only steal frontmost
status when a dialog needs to be displayed, I have a set of
convenience methods I use:
- (void) activateGracefully
{
// First, do we even need to activate?
if ([NSApp isActive] == NO)
{
GetFrontProcess(&_activeApp);
_interruptedOtherApp = YES;
// Make ourselves frontmost!
[NSApp
activateIgnoringOtherApps:YES]; } }
- (void) deactivateGracefully
{
// Always deactivate ourself if we are active
if ([NSApp isActive] == YES)
{
[NSApp deactivate];
// If we interrupted somebody when we last activated, then
// kindly reactivate them
if (_interruptedOtherApp == YES)
{
SetFrontProcess(&_activeApp);
} } _interruptedOtherApp = NO; }
If you called "activateGracefully" just before displaying your
window, and "deactivateGracefully" just after, you might see a
very satisfactory behavior. (You'll need to define the instance
variables _activeApp and _interruptedOtherApp).
Daniel
On Nov 5, 2005, at 1:17 AM, Justin Williams wrote:
Greetings,
I am adding keyboard access to my menu bar based to-do list
application so that users can bring the application forward no
matter what application they are in.
When the user presses their hot key or clicks the menu bar icon
to launch the application, the application launches as it should
and posts a notification letting me know that the window has
application's main window has dropped down.
From here the user should be able to use the arrow keys to
navigate the outline view and manipulate data. Unfortunately,
the previous application they were working in still has the
focus of the keyboard.
When the notification posts letting me know the main window has
dropped this code is executed:
-(IBAction)checkOffActivated:(id)sender {
[oWindow makeKeyAndOrderFront:self]; [oOutlineView
selectRow:1 byExtendingSelection:YES];
}
While the row is selected in my column view, the oWindow window
still doesn't have the focus of the keyboard until I click the
mouse on it. If you would like to see this in action (its
somewhat difficult to explain) you can download this beta of the
application:
http://www.carpeaqua.com/co35a1.zip
To summarize, I don't understand why calling
makeKeyAndOrderFront isn't giving my window the focus as it should.
Any suggestions are welcomed. Thanks.
__________________________________________________
Justin Williams email@hidden
work: www.maczealots.com play: www.carpeaqua.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden