Re: Connecting actions to menu
Re: Connecting actions to menu
- Subject: Re: Connecting actions to menu
- From: Brian Webster <email@hidden>
- Date: Fri, 22 Jun 2001 16:49:19 -0500
On Friday, June 22, 2001, at 03:09 PM, cocoa-dev-
email@hidden wrote:
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.
Firstly, note that there is in fact a first responder for each
NSWindow, usually the "focused" object in that window. The very
first object that gets a crack at an action message is the first
responder of the key window. There is also a big difference
between mouse events, key events, and action messages. Mouse
events don't touch the responder chain at all (although action
messages triggered by a mouse event do, such as the action sent
by an NSButton), and key events follow a different path that
action messages as well.
If I click on a button (which is a view which is a responder),
the button is likely to be the first responder.
This is true for some NSView classes, but not generally for
NSButton. Each subclass of NSView determines whether or not it
can become the first responder by implementing the
-(BOOL)acceptsFirstResponder and -(BOOL)makeFirstResponder
methods. NSButton returns NO for these, so clicking on it does
not make it the first responder.
If I type in
a TextView, the text view is likely to be the first object to
properly have a shot at responding.
Yes, as NSTextView does accept first responder status.
If I click on a pop-up
that is in a different view from the aforementioned button,
it (being a view, being a responder) is likely to be its own
first responder, and to have a different responder chain (because
it is in a different view hierarchy)... but, in each case, the
object mentioned doesn't have to be its own first responder.
As I understand it, we have the option of setting it up so that
the first responder for the button is something completely different.
I think there is some terminology confusion going on here. Any
NSControl (NSButton, NSPopUpButton, NSSlider, etc.) or an
NSMenuItem has a target and an action. If the target points to
a specific object, the control's action message gets sent to
that target only, and that's that. It is when the target is set
to nil when the responder chain gets involved. Connecting a
control to the First Responder icon in IB is equivalent to
setting that control's target to nil. So the term "first
responder" really means a single window's first responder, but
due to the labelling of the icon in IB, it is also thought of as
being "the object that responds to an action message targeted at
nil", and these are usually two different things.
When an action is sent to a nil target, AppKit "walks the
responder chain", meaning that it tests objects in a certain
order to determine what object should receive the action
message. The key window's first responder, which is usually the
focused GUI object of that window, but can also be set
programatically to a non-visible object as well, is the first
object that has the possibility of responding to the message.
If that fails, AppKit goes on to the next object, and the next
object, in the order outlined in the NSResponder docs, until it
either finds an object that implements the action message, or it
runs out of objects and gives up. The same set of objects is
walked when menu items are validated, helping guarantee that
menu items won't be active if there is no object ready to handle
their action message.
The responder chain is definitely dynamic and most of the
changes come whenever the windows of the app change their
main/key status or when a window's first responder changes, e.g.
when a text field is focused. nil targets are most commonly
used with menu items, as they need to be able to apply to the
window the user is currently working in, which changes all the
time. Most (but certainly not all) controls, at least in my
experience, are usually better off having a specific object as a
target, since they usually work only in a specific context, i.e.
the one already determined by the window they're in.
So, the short response to your thoughts above is: yes and no. :-)
--
Brian Webster
email@hidden
http://www.owlnet.rice.edu/~bwebster