> On 3 Oct 2015, at 03:40, Quincey Morris <[email protected]> > wrote: > > On Oct 2, 2015, at 15:03 , Jonathan Mitchell <[email protected]> wrote: > > “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. Moving the call site makes no difference. The posted code is padded out with test logic.
> > 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. I would say this has occurred already. Looks as if you cannot reassign an 10.10 NSViewController -view’s next responder. > > 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. The responder chain is, as you know, very flexible. I used the FOSS XSViewController component to manage the responder chain. This has a distinct design, placing the view controller responders above the views and below the window. It has worked well for me and you can choose which controllers to insert into the the chain and which to omit, It however looks like it really doesn’t fly with the 10.10+ NSViewController changes. > 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.) The target app is basically a form processor and has ~300 nibs swapping in and out of a single document window. The view hierarchy is just too deep to let the window controller redirect the actions. Plus I have used the responder chain in preference to a constructing a second network of -delegate references (a custom action sender class enables interaction between the action sender and the eventual action receiver). Ahh well, looks like there might some bullet biting ahead… Thanks for the FWIW J _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
