On Mar 24, 2017, at 11:11 , Daryle Walker <dary...@mac.com> wrote: > > I have a re-explaination, including a picture, at …
I think I’m beginning to understand what you’re asking. Part of the problem is that Apple has never properly documented the use of storyboards on macOS, and there seems to be no standard pattern for doing many of the things that we used to do when using XIBs instead. If I understand correctly, you have a window with an associated custom subclass of NSWindowController. The root view controller is a NSSplitViewController, with a NSViewController on the left, and a NSTabViewController on the right. Each of the tabs has a NSViewController, with a table view in one tab and a text view in another tab (based on what you said in earlier posts). My structure may not be exactly the same as yours, but it’s something like that, right? Now, in some of the NSViewController views, you need to use a NSArrayController or NSObjectController, which is added directly to the storyboard. The question then becomes: how to connect the array or object controller to its content (which lies outside the storyboard) and/or establish an outlet to the array or object controller that gives you a programmatic reference to the object in the nib. (In a XIB-based design, this is straightforwardly done via the File’s Owner pseudo-object.) I think the short answer is that you should create a subclass for each NSViewController in your tree of controllers. You *could* subclass the split and tab view controllers too, but there’s no real need. The subclass would contain whatever outlets and properties providing access to model data it needs for its particular view. Each VC would have its own set of object and/or array controllers, and each object/array controller would bind or connect to its own VC. The only remaining problem is how to establish programmatic references between the WC and the VC subclasses, in particular how to make model data available to the VCs. — If this is a non-document app, I would recommend you create a class property in your WC subclass that holds a reference to your singleton WC of that subclass. This reference would be set in an override of the WC init method. — If this is a document-based app, I would suggest that your VC subclasses use KVO to observe themselves along key paths of the form “view.window.windowController.document.model…”. You could, for example, create a derived “model” property that returns “view.window.windowController.document.model”, along with a class “keyPathsOfValuesAffectingModel” method to make the derived property KVO compliant. You can then bind UI elements through the model property. The only thing to be careful of is that the derived “model” property will be nil initially, so your UI has to do something sensible until the model reference is available (in particular, not crash). — Alternatively, you can have the WC walk the tree of VCs, injecting a reference to itself in each VC of known custom subclasses. Does any of that help? _______________________________________________ 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
