On Jun 15, 2011, at 13:12, Luc Van Bogaert wrote: > 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.
You're not logging the tree, you're logging one path through the tree from *a* view up to the window. There's no easy way to log the entire tree, because there aren't any down links, only up links. I don't think "contains some text fields" is an accurate description. Your side panel view contains a view which contains a text field. Since that text field is first responder, the field editor (a text view) is displayed on top of it, so what you're seeing here is the nextResponder hierarchy when the field editor is in place. (The intermediate view between your text field and the field editor is probably responsible for drawing the box around the active field editor.) This is just one more way the nextResponder-based tree structure doesn't match the logical responder chain tree structure. > 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. This is what it looks like when no first responder has been set, or if there's no view prepared to accept first responder status. In that case, the window itself is the first responder. (This is documented.) Remember that what you're dumping here is not (as well as not being the entire nextResponder tree or the responder chain tree) the view hierarchy either. So now three concepts are in play: the nextResponder-based tree structure, the logical responder chain tree structure, and the view hierarchy tree structure. They're all related, but they're not the same. When a view that can be first responder is made first responder (as a result of any of several possible automatic or manual mechanisms), this nextResponder tree fragment will get more complicated. The above is just what it happens to look like at this point in your program's execution. > 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. As I said above, you aren't logging the responder chain, you're logging the nextResponder tree, and not even all of that. Plus, all three tree structures change over time as the UI is presented in different ways, so the snapshot you see at 'applicationDidFinishLaunching:' may never even be seen by the user. By the time the window is displayed, things may have changed significantly. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
