Re: Interface item validation through first responder
Re: Interface item validation through first responder
- Subject: Re: Interface item validation through first responder
- From: Luc Van Bogaert <email@hidden>
- Date: Wed, 15 Jun 2011 22:12:46 +0200
On 15 Jun 2011, at 21:49, Quincey Morris wrote:
> On Jun 15, 2011, at 12:12, Luc Van Bogaert wrote:
>
>> Because things still don't work, I have tried to visualize the responder chain by adding this into applicationDidFinishLaunching:
>>
>> NSResponder *nextResponder = [self.window nextResponder];
>> do {
>> NSLog(@"%@", [nextResponder class]);
>> nextResponder = [nextResponder nextResponder];
>> } while (nextResponder);
>>
>> This just returns one line of output: "null"
>>
>> So does this mean my window doesn't have a next responder? If so, I'm completely lost about why that would be. But of course that would explain why the validation methods are never called.
>
> It sounds like you're thinking of the chain as running "down" from the window to its subviews (and, potentially, the subview view controllers). It actually runs in the other direction, "up" from window.firstResponder towards the window object, and *ends* at the window. (I mean, the window-specific responder tree ends there. The logical responder chain continues on to the window controller, etc, just not using nextResponder links.)
>
> If you want to see what (part of) the chain looks like, start your loop from window.firstResponder.
>
Yes, I think I'm starting to get my head wrapped around this, but please stay a little patient with me.
NSResponder *responder = [self.window firstResponder];
do {
NSLog(@"%@", [responder class]);
responder = [responder nextResponder];
} while (responder);
This indeed results in a tree of responder objects becoming visible:
2011-06-15 21:56:28.622 DotSketcher[3267:903] NSTextView
2011-06-15 21:56:28.623 DotSketcher[3267:903] _NSKeyboardFocusClipView
2011-06-15 21:56:28.624 DotSketcher[3267:903] NSTextField
2011-06-15 21:56:28.624 DotSketcher[3267:903] NSView
2011-06-15 21:56:28.624 DotSketcher[3267:903] DSSidePanelView
2011-06-15 21:56:28.625 DotSketcher[3267:903] NSSplitView
2011-06-15 21:56:28.625 DotSketcher[3267:903] NSView
2011-06-15 21:56:28.625 DotSketcher[3267:903] NSWindow
As you can see,the contentpane contains a NSSplitView, that contains a DSSidePanelView on one side, which finally contains some text fields. The other side of the splitview is set up in IB to contain a scrollpane and a custom view, which in turn will eventually be populated with one of two seperate views, instantiated from code.
Now, what I still don't understand is when I disable the creation of the DSSidePanelView, but leave in the creation of the views in the other part of the splitview, this is what I see:
2011-06-15 22:01:38.114 DotSketcher[3293:903] NSWindow
So now, the window's first responder is the window itself, or so it seems. Why is that? Why isn't the custom view inside the scrollpane, or even my own view that I've added in code not the first responder here? I would have expected one of these views to be at the top of the hierarchy, that is be the window's "first responder" instead of the window itself.
Our intention was to insert the view controllers into the responder chain by making them next responder to their views. But these views don't seem to be part of the responder chain as well, even though I've added them with addSubview: to a view that's part of one part of the splitview.
_______________________________________________
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