Re: Connecting actions to menu
Re: Connecting actions to menu
- Subject: Re: Connecting actions to menu
- From: Fritz Anderson <email@hidden>
- Date: Fri, 22 Jun 2001 18:50:39 -0500
At 9:52 PM -0700 6/21/2001, jgo wrote:
This appears to be another example of my thinking being along
a completely different curve from the pack.
The idea of a responder chain is elementary. An object can
handle an event related to it directly... or pass it up the
chain, or the task of responding might be passed off to a
completely different chain. The question of "What is the first
responder?", to me is "When this happens in this context, what
is the first object that should get a shot at responding?"
But context changes, so the first responder changes; it's
dynamic, not static, context dependent, not universal.
If I click on a button (which is a view which is a responder),
the button is likely to be the first responder.
Bingo! There's your problem. I think.
"First responder" is not the same as "the UI element that is
currently handling user events." It's a higher-level concept: The
first responder is the part of the program that is the focus of
commands from the user.
Low-level: The mouse button goes down. The location is traceable to
a particular control in a particular window. The control, a button,
highlights; it tracks the mouse while the button is down, adjusting
its highlighting as necessary. The mouse button comes up while the
mouse is within the button. The button unhighlights, and now the
program has to do something about the button click.
High-level: There is some text on display. You can select some of
it, and when you press a button, it redisplays as italics.
Notice that for the low-level event handling, there's no need to make
special note of any data or display: It's all about the behavior of
the button, which is the same regardless of what your program does or
what state it's in. This behavior is so standard that your program
doesn't care about the details, and Cocoa doesn't give your program
any access to them.
What you do care about is: A button-push (or a menu selection, etc.)
means a command. Commands apply to things. What thing does the
command relate to? In a Mac program, the user designates a noun as
the focus of action, and then sends it a verb.
If the button were attached to a single text field that couldn't be
partially selected, identifying the noun is no problem, because
there's only one possibility. The button could just send a message
like "makeItalic:" directly to the associated text field.
But if there are several text fields that might be served by the
button, or if the text is partially selectable, then there is no way
to identify the noun while you're building the nib file. Instead,
you send makeItalic: to First Responder, which is like an in-box for
the message, "the user wants to make something italic; find something
that cares." The First Responder is "the current noun."
Now, the trick is to make sure that something that cares about the
makeItalic: message is in the responder chain. But because the Mac
model is noun first, then verb, that isn't your problem while you're
wiring up the Italic button. All a button does is issue one verb.
You take care of the noun when responding to other events, such as
text selections. When the selection changes -- a high-level concept,
indicating a change in the user's focus of command -- that's when you
(or Cocoa, automatically) set the first responder.
My own grasp of the concept is kind of C-minus, so I'm prepared to be
corrected.
-- F