Re: Mac containment segues, and prepareForSegue
Re: Mac containment segues, and prepareForSegue
- Subject: Re: Mac containment segues, and prepareForSegue
- From: Fritz Anderson <email@hidden>
- Date: Tue, 28 Oct 2014 10:26:07 -0500
You’ve gone to trouble; thank you.
However, I need some help understanding your answer. I can’t find a “Container
View Controller” in the Xcode 6.1 object library. Typing “contain” in the
search field gets you a “container view,” which is an NSView. The only special
thing about it seems to be that it comes pre-populated with an embed segue to a
new NSViewController. You can drop a view into a view-controller scene, but not
into a window-controller scene.
Searching for Controller gets you [blue] descendants of NSViewController; [green]
the NSController (object, array, tree…) family; and [blue] data controllers for
scripting and Quartz Composer.
Only the view controllers can be dropped into the canvas and serve the window
controller as content controllers. None of them (apparently) gives the window
controller any clue of their existence.
I see NSWindowController conforms to NSSeguePerforming, but as we found,
prepareForSegue… never hits the standard-issue window controller, and in fact,
I don’t see how you can attach an NSStoryboardSegue to a window controller at
all. I understand from your comments that other containment relationships
(e.g. from split-view controllers) aren’t segues, either; that’s what I see, too.
I have a workaround — cut the window-content relationship off and make the view
controller a standalone object in the storyboard, with an identifier. The window
controller can load it, initialize it, keep a reference, propagate a represented
object, and install its view as the content view of the window. That makes some
kind of sense, but IB posts a warning that you’re not spozed to have windows
without content controllers.* Thus my question about the correct way to do it.
My design question is less urgent now. But controller hierarchy is an essential
design pattern; and Apple’s storyboard template recommends a way to practice it.
It’s my job to understand it. I don’t.
— F
* (Someone [me, for a second or two] will think of posting a notification from
the view controller to let the document know about itself. For the benefit of
the archives: More than one document might be loading windows at the same time,
as it might be in a state-restoration process that is within contract if not
currently used. For at least one document, the first notification it sees will
be for another document’s views.)
> On 28 Oct 2014, at 2:47 AM, Roland King <email@hidden> wrote:
>
>>
>> On 28 Oct 2014, at 11:40 am, Fritz Anderson <email@hidden> wrote:
>>
>> I'm glad of the correction.
>>
>> Yes, I am speaking exactly about the "relationship" link
>>between the window in a window controller scene and the view in the
>>view controller as provided in the template's Main.storyboard.
>>
>> I think it absurd that there is no obvious way for a document class
>>that loads that window controller to get at the contents of the vote
>>controller, even to the extent of passing on a Core Data context.
>>
>> It being absurd, it's evident I'm missing something embarrassingly obvious.
>>
>> [Top-posted because I'm using my iPhone]
>
> I just watched the WWDC video you were talking about, had an hour in the
>gym with nothing better to do. That video of course uses different terminology
>from everything else I’ve seen before, however if you watch the piece where
>they first talk about prepareForSegue and listen carefully to what’s being
>said and how it’s being compared to iOS, I’m pretty sure that they are only
>talking about *presentation* segues, not the ones at the top of the slide
>which they call *containment* segues.
>
> later in the talk they first talk about their containment stuff, like
>splitview etc, and they don’t mention any prepareForSegue on that, then
>they talk about “Triggered” segues, and those are the ones which have
>identifiers and which use prepareForSegue. Those are the popover, modal etc
>etc. segues.
>
> Just to make things a little more complicated, there is such a thing as a
>Container View Controller (you can drag it out of the well and dump it on
>a storyboard), that has an Embed segue which does have settable name and
>does call prepareForSegue. So if you write your own containers, you get the
>call, I have.
>
> So from all that I deduce that what in that video is called ‘containment’
>actually appears on storyboards called ‘relationships’ and are segues
>in name-only, they don’t trigger prepareFromSegue, you can’t name them,
>they are lines on the storyboard. The segues which are real, and cause
>actions and can be hooked into are the triggered segues which cause popups
>and modal windows etc. Those you can name, those you get the callback for.
_______________________________________________
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