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 <r...@rols.org> wrote:
>
>>
>> On 28 Oct 2014, at 11:40 am, Fritz Anderson <fri...@manoverboard.org> 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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
