[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Correct way to handle kEventCommandUpdateStatus?

Subject: Correct way to handle kEventCommandUpdateStatus?
From: Jim Correia <email@hidden>
Date: Fri, 29 Aug 2003 14:17:30 -0400

What is the correct way for handling kEventCommandUpdateStatus?

The Handling Carbon Events documentation gives this example:

For example, you can use this hierarchy to enable or disable your programhs menu items according
to circumstances. This behavior is controlled via events of type kEventCommandUpdateStatus,
which ask whether a particular item should be enabled or disabled on the menu. On receiving
such an event for, say, the Close command on your programhs File menu, you might have an
event handler associated with the application event target (the outermost target in the hierarchy)
disable the menu, while a handler associated with an individual window enables it. If your
program has at least one window open on the screen, the event will be handled by the windowhs
event handler; if not, it will propagate outward to the application event handler. The Close
command will thus be enabled if there are any windows present, but disabled if there arenht.

So given an application with a custom window which can respond to kCommandFoo and kCommandBar following this example my window should enable kCommandFoo and kCommandBar when appropriate. The application can always disable them so they aren't enabled if a window which can handle them is around.

However, this doesn't appear to scale well.

If my window can handle 100 commands, then the application also has to know about those specific 100 command ids so it can disable them if the event percolates up to the application.

Am I missing something in how this event should be handled conceptually? Is there a better way to deal with this situation?

Jim
_______________________________________________
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.

Follow-Ups:
- kEventCommandUpdateStatus, slow typing, and menu key commands that don't contain the command key
  - From: Jonathan Guyer <email@hidden>
- Re: Correct way to handle kEventCommandUpdateStatus?
  - From: Eric Schlegel <email@hidden>

Prev by Date: Re: kDataBrowserColumnView:How to draw the content?
Next by Date: Re: cursor management
Previous by thread: TVector for xTalk glue.
Next by thread: Re: Correct way to handle kEventCommandUpdateStatus?
Index(es):
- Date
- Thread

Home