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: Philip George <email@hidden>
- Date: Fri, 19 Jul 2002 05:08:49 -0500
I have about 20 beta testers who independently and unanimously
complained about this behavior. The reason they notice is because my
NSStatusItem doesn't have a menu, just an image, so it sort of sticks
out like a sore thumb in my case. If it had a menu, IT would pop open,
but since it doesn't it seems odd that other menus should be activated
by it. It is a problem that needs to be corrected before I release this
product; period.
Furthermore, NSStatusItems contain default views which can be swapped
out for whatever kind of view you want (as long as it subclasses from
NSView at some point in its family hierarchy). That view can then add
subViews and so on and so on. So, yes, we are talking about views
here. That is, in fact, exactly how my app is layed out. The really
bizarre thing is that [[[statusitem view] window] windowNumber] returns
a valid NSWindow number--very strange, but possibly relevant nonetheless.
I agree certainly that Apple probably wouldn't consider this a bug, but
nonetheless, it is a problem which did not escape the attention of a
single beta tester, and none of them had good things to say about it.
THAT is why I need a workaround.
Although sometimes I too fall prey to responding to threads with
skepticism, "It can't be done." / "Why would you do that?" / "You
shouldn't do that." are not going to help me get this product launched
on time, so please refrain if that is all you have to say.
So, if anyone has any suggestions, I'm still all-ears.
- Philip
On Friday, July 19, 2002, at 01:08 AM, Brent Gulanowski wrote:
>
*This message was transferred with a trial version of CommuniGate(tm)
>
Pro*
>
>
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.