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: Jonathan Mitchell <email@hidden>
- Date: Fri, 06 Nov 2015 13:07:18 +0000
- X_v_e_cd: d7c0272854e43a22330942822fe7419d
- X_v_r_cd: 8687607c2e1364b71f6a1392f15566f7
This thread is a bit long in the tooth but I thought I would conclude it.
My final solution to this was not to try and split a separate NSResponder class off from my NSViewController.
I could have been gone down this route but the sheer amount of donkey work put me off.
The app was designed to work with NSViewController instances between the NSWindow and the NSWindowController in the chain - period.
The 10.10 API changes simply invalidated my design.
You could argue that the NSViewController should not have been inserted into the chain as I had done but there was nothing that I know of that would have mandated against this design.
Anyhow, my fix was to give my controllers an additional NSViewController proxy property.
The proxy does not load the controller’s nib, it merely references the parent controller’s view and participates in the auto responder chain building.
The parent controller can then be inserted higher up in the responder chain as before.
https://github.com/mugginsoft/XSViewController/commit/29b406a4e1882edea2203eaff3c44f1c6a2f4cbd
> On 4 Oct 2015, at 11:02, Jonathan Mitchell <email@hidden> wrote:
>
>
>> On 3 Oct 2015, at 18:43, Quincey Morris <email@hidden> wrote:
>>
>>
>> I suggest you consider breaking your view controllers apart into two objects. One, a “view responder” would be a NSResponder subclass that you insert into the responder chain just below the window controller. The other, an actual NSViewController subclass, would be inserted into the responder chain wherever the frameworks want, or possibly not at all pre-10.10.
> That’s a good idea!
>
>>
>> Ideally, all of the business logic would be moved from its current home in the view controller to the view responder, including the action messages. All that’d be left in the view controller would be the outlets (if any), and the viewDidLoad logic necessary to prepare the view itself (and also to create the view responder, and insert it in the responder chain). Alternatively, you could keep all the local-to-view logic in the view controller, and put only the trans-view logic in the view responder, but this may get a bit messy if both share the same custom data structures.
>
> The business logic is all in a separate framework.
> The view controllers simply hookup the UI bindings by calling into the BL.
> So I might go along the lines of of an additional lightweight NSResponder that acts an action receiver that routes actions back to proxies in the view controller.
>
> Or, it might be simpler to just accept the 10.10 design changes and refactor accordingly.
> In the long term this might be best in terms of reducing overall complexity.
>
> Thanks a bunch for you input. It helped a lot.
>
> J
_______________________________________________
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