Re: Hooking into responder chain, and NSTabViews - or dont?
Re: Hooking into responder chain, and NSTabViews - or dont?
- Subject: Re: Hooking into responder chain, and NSTabViews - or dont?
- From: Raleigh Ledet <email@hidden>
- Date: Fri, 15 Jul 2011 11:30:08 -0700
Hi David,
As you switch views due to tab switching, the newly added view sets up it's next responder based on the view hierarchy. The new view coming in doesn't know anything about your view controller and simply wires up it's newt responder as it's parent view.
You have a few options here:
1. Inject your controller into the responder chain after your tab view. This way changing the child view of the tab view won't affect your controller
2. After you swap your tab view, re-inject your controller into the responder chain after the new tab view
3. Rework your tab view so that there is a dummy container view between the tab view itself and the child views. Now you can inject your controller in the responder chain after the container view (and hence before the tab view). All the child view changes in the container view should not affect your controller view responder chain placement.
-raleigh
On Jul 15, 2011, at 4:04 AM, Mirabito, David wrote:
>
> Hello,
>
> [re-sending: previous attempt yesterday sent from a non-subscribed email
> account. Sorry in advance if it dupes!]
>
> I have a custom view (DJMTerminalView) and a controller object
> (DJMTerminal) with the idea being that the view is only responsible
> for drawing (draw char foo at position bar with attributes baz)
> however the controller tells it to.
>
> I set them up on-demand programmatically, spawning into new tabs of a
> tabview, snippet:
> NSTabViewItem *newtab;
> newtab = [[NSTabViewItem alloc] initWithIdentifier:@"NiceID"];
> [newtab setLabel:[NSString stringWithFormat:@"Cond", num_tabs]];
> [consolesTabView addTabViewItem:newtab];
>
> NSRect theRect = [consolesTabView contentRect];
> DJMTerminalView *termView = [[DJMTerminalView alloc]
> initWithFrame:theRect];
>
> [newtab setView:termView];
>
> DJMTerminal *theTerm = [[DJMTerminal alloc]
> initWithTerminalView:termView];
>
> This works as expected, new tabs appear and output is properly
> directed to the appropriate one as the app continues to run.
> Now the controller is really what wants to catch the key presses so I
> figure its best to inject it into the responder chain.
>
> Q1: Is this a sane pattern to follow in the first place?
>
> I do so in the controller¹s ³initWithTerminalView:(DJMTerminalView
> *)aView² method:
> [self setNextResponder:[aView nextResponder]];
> [aView setNextResponder:self];
>
> Q2: Is this an accepted way to do this?
>
> Now even this works especially if during testing I don¹t instantiate
> the terminals into a tab view.
>
> If they are tabbed (as I eventually intend), then it works until I
> switch tabs back and forth. Output continues to work, but the tabview
> seems to like re-setting the view¹s nextResponder whenever the visible
> tab changes thereby breaking interaction with the terminals.
>
> Q3 How best to work around this?
>
> I have an inkling that I could alternatively abandon the idea of using
> firstResponder for this, and simply have the view handle its own
> keypresses as first, and call the controller manually with something
> like:
> [myViewController handleKeyPress:theEvent];
>
> I guess I¹m just after recommendations and hints to Obest practice¹
> either way before I start down either path.
>
> Cheers,
> DavidM
>
> _______________________________________________
>
> 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
_______________________________________________
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