Are you inferring it's possible to assign a command ID to a menu
in a Cocoa app and then grab it from a Carbon event handler I
have running (assuming I disconnected it from any Cocoa methods)?
You mean "are you implying". :)
That's something I've always wanted to be able to say. Still not
sure how people get those two words confused.
Probably because in a previous life I studied Latin, French, Spanish,
German, and spent some time in the spheres of Langue d'oc. Not to
mention that a good portion of my youth was spent in a society where
Fringlish was the norm and Franglais got me a summer job.
Lisa observes that Marge has been spending more time at Moe's than
Homer has.
Homer: Just what are you inferring?
Lisa: I'm not inferring anything! You 'infer', I 'imply'!
Homer: What a relief!
Homer, the guy who remarked, amongst other things, the destruction of
Atlantis ~900 BCE?
Yes, that would be possible, assuming that you could assign a
command ID to a menu using Cocoa. As far as I know, there's no
Cocoa API to do that.
To other people: Please don't infer from this statement that it's
trivial to mix MenuRef logic and NSMenu logic. It's not.
AFAIK, there isn't either an API to set a cocoa command id..
However, the cocoa stuff "randomly" assigns command IDs to menu
items, they may not/will not be the same across application
launches. The cocoa handler also "freaks out" if there are more
menu items in a MenuRef than in the NSMenu that wraps the MenuRef.
The AppKit event handler (AppKitMenuEventHandler()) assumes an
untouched menu and will throw exceptions if the NSMenuItems count
is less than the index of the selected item.
This also means you cannot easily insert non-NSMenuItems into a
cocoa menu.
The cocoa bridge will often completely rebuild its internal MenuRef
every so often and even if you did add your own Carbon Menu items,
they could be wiped out on a rebuild. The bridge isn't the most
optimized thing and does a lot of things in bizarre ways (like
calling ChangeMenuItemAttributes() bunches of times for each menu
item after it calls InsertMenuItemTextWithCFString()).
And you also cannot insert a Carbon MenuRef into the cocoa menu bar
or as a submenu of a Cocoa NSMenu without a bit of trouble. In the
former case, after you add the item to the root menubar, you'll get
a bizarre fake menu that appears the next time an NSPopupButton's
menu is open (and NSMenu's don't have MenuRefs until they are
opened and/or added to the menu bar)
So the fact that NSMenu sits on top of the Carbon Menu Manager
doesn't benefit the far majority of people and there's no way to
"exploit" this knowledge without doing.... evil... things due to
the assumptions Cocoa makes about completely owning the MenuRefs.
Thanks for the info, however my particular purpose was to override a
menu connection in an AppleScript Studio app and deal with it in
Carbon. Even though it's not the solution I wanted, a category has
done the job for now. I had no need to add or delete menu items in
the app.
Cheers,
Philip Aker
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
