Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kEventCommandUpdateStatus, slow typing, and menu key commands that don't contain the command key

At 2:37 PM -0400 8/30/03, Laurence Harris wrote:

The only solution I've found is to use kEventMenuEnableItems handlers. You
don't really give details of how you're using them or how you're adjusting
your menu items.

Sorry about that; I wasn't clear. Alpha is largely driven by Tcl scripts (sort of the way emacs is driven by lisp scripts). Those scripts do the menu adjusting. Likewise, we do our own key bindings (in gross violation of the HIG, Alpha allows you to bind any key combination to any Tcl script without necessarily associating it with a menu item; we've got a kEventTextInputUnicodeForKeyEvent handler that calls through to our crufty old code for that).

Are you returning eventNotHandledErr from all these
handlers? Are you not using kEventMenuEnableItems and
kEventCommandUpdateStatus to adjust your menus? Do you have
kEventMenuEnableItems installed on any windows?

We're not using them. We've got these stub handlers for kEventMenuEnableItems and kEventCommandUpdateStatus installed on the application that just return noErr.

Keeping in mind that I have no idea what I'm doing [*], I've been experimenting a little bit with putting a kEventMenuEnableItems handler on this modal window with the YAST control, on the YAST control itself, or on the Edit menu, but our stub application-wide handler blocks them from propagating to the standard handler and its invokation of kEventCommandUpdateStatus (?), so the Edit menu is never enabled or adjusted. If I remove the application-wide handler, then the Edit menu works properly, but I'm back to molasses typing in the YAST control.

If I return noErr for kMenuContextMenuEnabling and eventNotHandled for all other kEventMenuEnableItems, then the Edit menu appears enabled, but again with the slow typing. If I return noErr for both kMenuContextMenuEnabling and kMenuContextKeyMatching events, then typing is fast, the Edit menu gets updated properly, but it remains dimmed in the menu bar (it works, but it's dimmed). Moreover, I'm concerned about the issues you raised with kMenuContextKeyMatching a few months ago <http://lists.apple.com/archives/carbon-development/2003/Jun/30/poortypingspeedwithkeyfi.002.txt>, although because we do our own command key matching, perhaps that issue is moot. At this point, this is the "solution" that I'm probably going to go with; I've got sufficiently major issues to deal with in the way this modal window is created from Tcl that a dim Edit menu actually seems pretty tolerable.

[*] I didn't write any of the limited CarbonEvent handling that we currently have and my understanding of CarbonEvents in general is entirely theoretical (I've read all the stuff that you'd have me read, Larry 8^), but I've not tried to actually do it before).

--


Jonathan E. Guyer
<http://www.his.com/jguyer/>
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: kEventCommandUpdateStatus, slow typing, and menu key commands that don't contain the command key (From: Laurence Harris <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.