Many thanks again for your reply, much appreciated, and for your suggestions.
Actually, I think I might be able to improve things with a better use of
-menuHasKeyEquivalent..., if I understand correctly.
> It's not quite as bad as "all the menus are
> populated for every key combo." What is supposed to
> happen is, the first time a key combo is hit, menus are
> populated starting from the right until a match is found.
> But it also remembers the KEs for each menu, and when a
> remembered KE is hit, it first populates the menu that it
> was last found in. The only time it will routinely populate
> every menu is if a key equivalent is not found, and users
> normally don't care about the performance of unmatched
> key equivalents. If you're seeing different behavior,
> it would be worthwhile to investigate why.
This fits with the behaviour I'm seeing. The trouble is that, depending on the
size of the project, some of the menus can be very big, so the first time the
user hits each key equivalent, there can be an unacceptable delay as these
menus get re-populated. These particular menus do have icons, so your second
suggestion might help here. However, thinking about this some more based on the
information you have given, I've realised that my initial example of the styles
and script elements menus most likely isn't the problem at all. The problem is
the larger menus that get built based on the contents of the project, (for
things such as, Link to Document > [list of documents as menu items], Append
Selected Text to Document > [list of documents as menu items] and so on).
Whilst it is likely that the user would apply key equivalents to the menu items
for styles and script elements, it is highly unlikely that the user would ever
apply a key equivalent for one of
the items in these large menus that list the documents in the project. So if I
could use -menuHasKeyEquivalent... to tell the program not to look for key
equivalents in certain menus - these bigger menus - but to carry on as if the
delegate method wasn't implemented for the other menus and populate them as
normal, then I think things would be fine.
The trouble is - unless I'm doing something wrong, which is likely - that
-menuHasKeyEquivalent... doesn't seem to work like this; it seems to be an all
or nothing deal. I can return NO, in which case none of the menus get
populated. But if I return YES, the application crashes - it seems that I have
to fill in the pointers passed into the method. But what I really want to do is
return "NO" for the larger menus that will have no key equivalents, but for the
other menus have it act as though the delegate method isn't implemented - which
"YES" doesn't seem to do. Is there a way to do this without having a different
delegate for the menus that get populated with the project contents (i.e.
implementing -menuHasKeyEquivalent... to return NO for the delegate of those
menus and not implementing it for the delegate of the other menus)? Having a
separate delegate object just to perform this one task seems a bit of an
awkward workaround, which is why I think I
must be using -menuHasKeyEquivalent... incorrectly.
Apologies again for more long-windedness!
Thanks again and all the best,
Keith
>
> In any case, your description makes sense, but now I'm
> not sure what behavior you want. In order to know if a menu
> has a user key equivalent, we need to construct the menu,
> which means populating it; if the menu is slow to construct
> then determining user key equivalents is necessarily slow as
> well. Absent more information, I have two suggestions, both
> of which depend on speeding up menuNeedsUpdate:
>
> 1) When you construct the menu, you can ask each item for
> its user key equivalent, and cache that keyed by title.
> When populating a menu for key equivalent matching, you can
> elide items that you previously found to have no user key
> equivalent.
> 2) Depending on the reason for the slow menu construction,
> you may be able to do less work for calls to
> menuNeedsUpdate: triggered for user key equivalents, such as
> avoiding loading icons. I think checking to see if the call
> occurs between NSMenuDidBeginTracking and
> NSMenuDidEndTracking notifications should help there.
>
> -Peter
_______________________________________________
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]
