Hi,
Many thanks for the reply.
>
> If you implement menuHasKeyEquivalent:, then the menu does
> not get populated for matching key equivalents; NSMenu
> assumes that your code does not need it to be populated.
> This puts the onus of supporting user key equivalents on the
> app itself, and since there's no easy way for an app to
> implement this, implementing menuHasKeyEquivalent: is not a
> good idea unless the menu has custom KE handling or should
> never have a KE.
I haven't found this a problem with anything except the dynamically-created
items. Everything else works fine with keyboard shortcuts that are defined in
the System Preferences.
> There's no reason why this should be slow. Have you
> tried profiling it with Shark? Where is its spending its
> time?
>
> Perhaps you are completely rebuilding the menu every call
> to menuNeedsUpdate:. The menu state is not disturbed
> between calls to menuNeedsUpdate:, so you can detect if the
> user has added or deleted a style since the last update, and
> if not, you do not need to do anything in menuNeedsUpdate:.
The trouble is that the styles were just an example. The application is quite a
big one, and there are a good number of menus that get dynamically created -
several of which are very likely to have changed between calls to
-menuNeedsUpdate:. For instance, my application has a "Create Link to Document"
submenu, which provides a list of documents in the application's source list so
that the user can create links between documents. Given that the onus of the
app is on structuring and moving documents around, the order and structure of
this submenu is likely to change a lot. If I checked for every instance of a
change in state to these menus, I'd have an awful lot of state-checking going
on. And even with this state-change checking, it would still be slower. From my
understanding and tests it seems that if -menuHasKeyEquivalent... isn't
implemented, then every time a key combo is hit, the app populates all the
menus and looks through them for the command
matching the key equivalent. This gets incredibly slow when menus are being
built dynamically - and so in my app, even with state-change checking, there
would be many occasions when certain menus need rebuilding and thus key presses
would become slower.
Sorry, that was a bit long-winded. I hope that makes sense.
The problem seems to be when the dynamic menus get built, preventing system
shortcuts from affecting them...
Thanks again and all the best,
Keith
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
