Re: NSStatusItem with no menu triggers menu tracking (repost)
Re: NSStatusItem with no menu triggers menu tracking (repost)
- Subject: Re: NSStatusItem with no menu triggers menu tracking (repost)
- From: Brent Gulanowski <email@hidden>
- Date: Fri, 19 Jul 2002 02:08:30 -0400
On Thursday, July 18, 2002, at 09:13 PM, Philip George wrote:
To recap: Simply single-click on any blank area of your menubar. After
releasing the mouse from the click (and before clicking on anything
else), hover the pointer over the system clockits menu will pop open.
This is what happens when I click on the NSStatusItem in my app, which
does not have a menu; it's just an image that, when clicked, triggers a
handler method. If you listen to the notifications being passed around
by the system, you'll see that in effect you're activating menu tracking
(when you didn't actually click a menu at all), which can only be
DE-activated by clicking something (anything).
First of all, there is no "menubar" in OS X -- ask Ondra, its a
"horizontal menu", treated like any other menu (despite its nice big blank
area -- just a spacer I guess). There is no NSMenuBar class.
It's interesting to look at the menu and status* classes -- these are not
NSView subclasses, they are using some other system. So your speculation
about views and subviews is unfortunately for naught.
Notice also that when you click on the empty part of the main menu (aka
menu bar), you can drag left to activate menu items, drag right to
activate status items, but dragging back left again gets no response from
the menu items. Interesting. -- Also, just realized that the going to the
left only works if you hold the mouse down, otherwise only the status
items respond. But the need to click off is true for the menu as well.
How can I combat this behavior now, without having to wait on Apple to
fix a bug, which they may not even consider to be a bug?
I don't see how it is a bug.
The bottom line (rephrased for clarity): I do not want menu tracking
enabled (or at least I want it immediately disabled again) when users
click on my statusitem.
You seem to be asking how to short circuit OS behaviour. I don't see that
as being possible. It's not in your method, you don't have any control.
Clearly at issue is the fact that the statusBar is NOT a menu, either, but
is in fact some kind of reserved real estate which shares the menu bar
area. Moreover, the statusBar owns all the area up there that is not
actually a menu, but always defers to the menu in the case that they
collide. The fact that menu tracking is enabled suggests that the
statusBar is perhaps inside a menu -- but not the same menu on the left of
the menubar.
Could it be that the statusbar itself owns a menu inside of it, and each
item has NSViews inside of them?
In any case, what is apparent is that menu tracking may have nothing to do
with anything -- the fact is that when you click in a menu, it enters a
modal event loop (I speculate). The same thing happens inside the
statusBar. In order to break a modal event loop, listen for the menu
tracking notification and generate a mouse up and put that into the
RunLoop which your Status Item is a part of. Hopefully that's the right
RunLoop for the StatusBar, which will then deselect. Unfortunately, if
this works, it will PISS OFF your users.
Why on earth do you want to interfere with the normal behaviour of the
Status Bar??
Brent
--
Inkubator: creating free, open source Mac games.
http://inkubator.idevgames.com - homepage
http://www.sourceforge.net/project/inkubator - project page
http://64.246.17.165/forum/forumdisplay.php?s=&forumid=17 - discussion
forums
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.