Re: another responder chain docs bug (validateUserInterfaceItem:)
Re: another responder chain docs bug (validateUserInterfaceItem:)
- Subject: Re: another responder chain docs bug (validateUserInterfaceItem:)
- From: Kyle Sluder <email@hidden>
- Date: Wed, 3 Feb 2010 08:42:24 -0800
On Wed, Feb 3, 2010 at 1:02 AM, Jens Miltner <email@hidden> wrote:
> Well, in my experience the truth is somewhere between the two:
>
> AppKit seems to go up the responder chain and call
> validateUserInterfaceItem: on each potential target (i.e. each responder
> that responds to the action message and responds to
> validateUserInterfaceItem:) until the first call to
> validateUserInterfaceItem: returns YES.
> If none of the potential targets returns YES from
> validateUserInterfaceItem:, the item is disabled.
Correct.
If a control's target is non-nil, and that target doesn't respond to
the action selector, the control is disabled. If it does respond to
the action selector, and doesn't do UI validation, the control is
enabled. Otherwise, the control is either enabled or disabled
according to the result of calling the UI validation method.
If a control's target is nil (aka First Responder), AppKit walks the
responder chain until it finds a control that responds to the action
selector. If it can't find one, the control is enabled. If it does
find one, logic proceeds as above.
While this has served well for the past 20 years, we find it's not
optimal. We'd like AppKit to continue searching, rather than abort, if
it finds a control that responds to the action selector but doesn't
validate, and we would like targets to be able to add pieces to the
responder chain dynamically (very useful for control delegates).
So Tim wrote OATargetSelection. It lives in our open-sourced
OmniAppKit frameworkâspecifically in -[OAAplication
sendAction:to:from:] and supporting methods. You can find it here:
http://github.com/omnigroup/OmniGroup/blob/master/Frameworks/OmniAppKit/OAApplication.m
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden