Re: How to implement NSSplitViewDelegate methods in an NSSplitViewController subclass
Re: How to implement NSSplitViewDelegate methods in an NSSplitViewController subclass
- Subject: Re: How to implement NSSplitViewDelegate methods in an NSSplitViewController subclass
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 07 Aug 2015 15:33:42 -0400
Thanks, that helps me to understand it a little better. But by calling super the way I showed in my original post, I am not making use of any result that might be returned by super's implementation of the method. And how could super's implementation return anything meaningful to my application anyway? My override is the only one that knows how to return a result that is meaningful to my application. I've always been comfortable calling super when it doesn't return a result, or when I am expected to use super's result for some purpose in my override. But it feels very bizarre to be calling a super implementation and doing nothing with whatever result it returns.
I guess what you're saying is that super takes advantage of my call to fiddle around with some stuff internally, and then it's happy to stand back and let me do what I will with my override.
But just for the heck of it I implemented several of these delegate methods without calling super, and they worked just fine. Very confusing.
--
Bill Cheeseman - email@hidden
> On Aug 7, 2015, at 1:09 PM, Quincey Morris <email@hidden> wrote:
>
> On Aug 7, 2015, at 05:47 , Bill Cheeseman <email@hidden <mailto:email@hidden>> wrote:
>>
>> I don't understand why the fact that NSSplitViewController "implements" these delegate methods requires my override to call super, or what calling super accomplishes in this situation.
>
> According to the latest header files, setting a different delegate on the controller’s splitView causes an exception. That means there really is no delegation pattern here (from your point of view). Instead, there are just some delegate-like methods you can override (but must call super if you do, in the ordinary way).
>
> Internally, of course, there is delegation going one, but it’s now an implementation detail.
>
_______________________________________________
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