Re: Problems with custom NSView subclass, IBPalette, and bindings support
Re: Problems with custom NSView subclass, IBPalette, and bindings support
- Subject: Re: Problems with custom NSView subclass, IBPalette, and bindings support
- From: mmalcolm crawford <email@hidden>
- Date: Wed, 26 Jan 2005 18:03:28 -0800
On Jan 26, 2005, at 12:33 PM, Scott Anguish wrote:
Should I call super at the beginning or end of my implementation?
I don't think it matters.
well, it can. It depends on if you're changing the values that
are passed to super
In that case I think it's obvious -- in the typical case when you don't
change any values, I don't think it matters...
Do I also need to call super for unbind? valueClassForBinding?
observeValueForKeyPath:...?
Probably, yes, I will check (unless Scott wants to chime in here?)...
yep... pretty much in general this is a rule... if you override
something, but still need the default behavior, you must call the
superclass.
the example in the doc shoes observeValueForKeyPath:... calling
super in fact.
Am I blind, or is this not documented? Your GraphicsView.m and
JoystickView.m classes in you GraphicsBindings example also do not
call
super. Is doing so only needed if one is making an IBPalette?
No, it's not documented. Please file an enhancement request.
as I said, calling super is probably the right thing to do unless
you're replacing functionality entirely
The documentation does not at the moment make clear that there is any
basic functionality implemented to support the NSKeyValueBinding
protocol by NSView (or by NSObject -- but see below) that needs to be
"retained" by subclasses -- indeed the introduction suggests the
opposite:
"This informal protocol is implemented by NSObject and its methods can
be overridden by NSView subclasses."
<http://developer.apple.com/documentation/Cocoa/Reference/
ApplicationKit/ObjC_classic/Protocols/NSKeyValueBindingCreation.html>
Empirical results suggest that the only place calling super is
necessary *for an immediate subclass of NSView* (clearly subclasses of
controls, for example, that expose their own bindings present a
different situation) is in a palette.
Furthermore, if you implement a direct subclass of NSObject and
implement observeValueForKeyPath:... to call super, then observe an
object, at runtime when your method is invoked you get an error:
*** -observeValueForKeyPath:ofObject:change:context: only defined for
abstract class. Define -[<Your Class>
observeValueForKeyPath:ofObject:change:context:]!
...
mmalc
_______________________________________________
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