Re: another responder chain docs bug (validateUserInterfaceItem:)
Re: another responder chain docs bug (validateUserInterfaceItem:)
- Subject: Re: another responder chain docs bug (validateUserInterfaceItem:)
- From: Andy Lee <email@hidden>
- Date: Wed, 03 Feb 2010 14:36:21 -0500
On Feb 3, 2010, at 11:42 AM, Kyle Sluder wrote:
> 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.
This is my understanding, but it is not quite what Jens wrote. The difference is in when the traversal of the responder chain stops. As you say, it stops with the first object that responds to the action selector, *regardless* of whether that object does UI validation, and *regardless* of what UI validation (if implemented) returns.
> 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
Thanks!
--Andy
_______________________________________________
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