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:32:41 -0500
.... oh, and when I talk about menus, I **DO** mean NSMenu objects.
They are **ADDED TO** an NSStatusItem. I never meant to imply that they
are one and the same; one contains the other. Check out the
NSStatusItem documentation to see what I'm talking about.
On some level, I'm glad you mentioned that though, because it made me
really think about this from a different angle. If I click on my
NSStatusItem, which does NOT have an NSMenu inside it, and yet it
triggers a "com.apple.HIToolbox.beginMenuTrackingNotification"
notification... I suppose that is a bug.
I will report it when I get a chance, but bux fixing can be a lengthy
process, and I don't have the luxury of time right now, so I still need
some pro-active suggestions for workarounds. I'm doing my homework over
here, believe me, but I'm running out of ideas.
- Philip
On Friday, July 19, 2002, at 05:08 AM, Philip George wrote:
>
*This message was transferred with a trial version of CommuniGate(tm)
>
Pro*
>
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.
_______________________________________________
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.