Re: Problems subclassing NSTableView and NSOutlineView
Re: Problems subclassing NSTableView and NSOutlineView
- Subject: Re: Problems subclassing NSTableView and NSOutlineView
- From: Scott Anguish <email@hidden>
- Date: Thu, 7 Jul 2005 04:55:22 -0400
On Jul 7, 2005, at 3:26 AM, Todd Blanchard wrote:
On Jul 6, 2005, at 11:21 PM, mmalcolm crawford wrote:
Per the documentation,
"The other methods—the class method exposeBinding: and the
instance methods exposedBindings and valueClassForBinding:—are
useful only in an Interface Builder palette."
Yes, but the docs imply that exposedBindings need not be written,
but exposeBinding: must be called, valueClassForBinding: is
apparently optional.
that could perhaps use some clarification.. the reference for
exposed bindings says
Returns an array containing the bindings exposed by the receiver. A
subclass can override this method to remove bindings that are exposed
by a superclass that are not appropriate for the subclass.
so you don't need to write it. you could override it and remove items
(as the ref says)
Overall, not very clearly spelled out. I see that the docs are
trying very hard to be complete and nooB friendly. They do this at
the expense of essential information and the great annoyance of the
experienced but busy. I would very much like to see something that
explains the interaction pattern, exactly who calls what, what is
already written, and what I have to write, a brief but complete
example, and that's it.
The interaction pattern between the common cases is coming to a
documentation update very shortly.
Its also clear that the lack of a public version of NSBinder is a
giant gaping hole in the framework. As soon as I saw the example
code I said "ICK! - That needs to be a class!" OK, so controllers
in general were an even bigger hole, but we are tantalizingly close
to being able to build non-trivial apps without code if only the
widgets were just a smidge more capable. It is quite frustrating.
If you want to build apps without code, you can't be subclassing
and adding new functionality. :-) _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden