On Jul 2, 2009, at 14:05, Andy Lee wrote:
Hm, you know what, it seems odd to me that the
NSValidatedUserInterfaceItem protocol doesn't include setEnabled: or
some such. The doc says, "If no responder returns YES, the item is
disabled." But how can the application know it *can* disable the
item, much less *how*, unless the item is guaranteed to implement
setEnabled:?
The answer to this is [obscurely] in the documentation:
http://developer.apple.com/documentation/Cocoa/Conceptual/UIValidation/Articles/implementingValidation.html#/
/apple_ref/doc/uid/TP40006268
"Before it is displayed, a user interface item checks to see if its
target implements validateUserInterfaceItem:. If it does, then the
enabled status of the item is determined by the return value of the
method. You can therefore conditionally enable or disable an item by
implementing validateUserInterfaceItem: in the target
object." [quote #1]
IOW, it's intended that the object conforming to
NSValidatedUserInterfaceItem should initiate its own validation by
calling validateUnserInferfaceItem. It enables or disables itself by
examining the return value, so it doesn't need an "enabled" property
that can be set externally to it.
If the above is true, then I think it pretty much clears up a lot of
the confusion generated in this thread.
However, there's more. Both of the protocol reference documents say
this:
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSValidatedUserInterfaceItem_Protocol/Reference/Reference.html#/
/apple_ref/doc/uid/20000467
By conforming to this protocol, your control can participate in this
validation mechanism. To validate a control, the application calls
validateUserInterfaceItem: for each item in the responder chain,
starting with the first responder. If no responder returns YES, the
item is disabled. For example, a menu item that sends the copy:
action message would disable itself if no responder in the responder
chain can be copied. [quote #2]
If "the application calls validateUserInterfaceItem: for each item in
the responder chain" is understood to mean that something (e.g. NSApp)
makes all the calls from a loop, then it clearly contradicts quote #1.
In fact, the answer can be deduced from:
http://developer.apple.com/documentation/Cocoa/Conceptual/UIValidation/Articles/ValidatingObjects.html#/
/apple_ref/doc/uid/20000745
Menus and menu items respond to an "update" method that triggers the
validation process. Something (presumable NSApp) presumable calls
'update' for the main NSMenu, and the 'update' calls trickle down to
the NSMenuItems, which then initiate their own validation.
A similar thing presumably happens starting from a windows NSToolbar.
The example laid out in this document pretty much explains how it's
implemented, and it suggests you could add similar functionality to
other classes by adding 'update' to them via a category.
IOW, quote #2 is plain wrong -- nothing directly calls
validateUserInterfaceItem: for each item in the responder chain.
Probably, something calls 'update' for everything in the responder
chain that implements 'update', but we don't really know how that works.
I really all makes sense, I think, although you could possibly argue
that the whole validation architecture is a bit whacked, and certain
argue that the documentation is royally whacked.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
