Re: NSView - trouble setting next responder on 10.10 - works okay on 10.9
Re: NSView - trouble setting next responder on 10.10 - works okay on 10.9
- Subject: Re: NSView - trouble setting next responder on 10.10 - works okay on 10.9
- From: Quincey Morris <email@hidden>
- Date: Fri, 02 Oct 2015 19:40:12 -0700
- Feedback-id: 167118m:167118agrif8a:167118sf-sXJ_rt6:SMTPCORP
On Oct 2, 2015, at 15:03 , Jonathan Mitchell <email@hidden> wrote:
>
> I am not disputing the veracity of the release notes!
When you first posted, I originally suspected (but had no specific knowledge) that the problem was your call to [super setView:] — specifically that this modified the responder chain, and that messed up what you were trying to do around it. I just checked the release notes, and they say this (in the part that you didn’t paste into your post):
> The following changes take effect for applications linked on 10.10 and higher:
>
> • NSViewController automatically adds itself into the responder chain. When a view is assigned, the view's current nextResponder is saved off. The view's nextResponder is then set to be the viewController, and viewController's nextResponder is set to be the previously saved nextResponder
“When a view is assigned” sounds to me an awful lot like “when [NSViewController setView:] is called”. You might have more success moving the super call to the beginning of your method, if you haven’t tried that already.
At a different level, though, I’d recommend you don’t do what you’re doing. My Apple tea-leaf reading instincts tell me that pretty soon you won’t have the choice of where to insert the view controller in the responder chain, so your methodology may not have long term survival prospects.
Unfortunately, the problem you’re trying to solve is awkward to deal with. Your intention makes perfect sense, but it happens to be in direct conflict with the design of the responder chain. Your solution only works if there’s only *one* view controller (for a given action message) below the window controller. If there were multiple candidate view controllers, it’d be ambiguous which one should receive the action vs. which one would receive it. If there’s only one candidate, it’s straightforward for the window controller to know or be told which view controller handles which action message. I think you’re better off, long term, in simply putting the/an action method in the window controller, and letting the window controller call the view controller action method directly. (You’d also need the view controller to have a ‘canDoAction’ method, so that the window controller could query it during interface validation, if you want to keep your view controller logic partitioned neatly.)
FWIW.
_______________________________________________
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