Apple

On Mar 23, 2017, at 2:06 PM, Quincey Morris <email@hidden> wrote:

On Mar 23, 2017, at 06:58 , Daryle Walker <email@hidden> wrote:

1. Created a split-view controller on Interface Builder with the two default 50% panes.
2. I added a third view controller. It's connected, i.e. has a segue link. But the picture still has only the two panes.

In a test project, when I added a third VC, the split VC showed all three with equal widths. Chances are, you’d already made some edits that caused IB to “hold” the old VC widths, so the third one was off the end of the split VC content area.

Nope, unless the whole storyboard is corrupt. Making a new split-view controller (with 2 sub-views) and tab-view controller (with 2 sub-views), and adding the tab-view controller as a third pane works as far as segue connections, but the visuals are still locked, like the first time. What did you do to add the third VC? Maybe I’m doing it the wrong way.

A resize gadget appears when I hover over the mid-bar but it doesn't actually move. I actually wanted two panes, but deleting the second puts the first at 100%, and I still can't resize it to show the new pane.

The resize cursor is apparently left over from editing old-style split views. With a split VC, you can’t rearrange the subviews here. Instead, resize the child view controllers directly.

Note, though, the NSSplitViewController *requires* the use of auto-layout to control the sizes of its child views. Dragging the child view controller out to a different size in IB doesn’t imply anything at run-time.

But the default split-view controller with two sub-views works just fine after dragging it out and connecting it to the window controller. Maybe I’ll do the full run-time constraint adjustment later, but why can’t I get the default set-up, with one swap out, to work now?

Instead, you must arrange the contents of the child view’s *subviews* using autolayout, and the split VC chooses split widths to accommodate the autolayout-determined child view widths. In particular, you can’t (AFAICT) set a fixed width on the child view itself, presumably because the child views will always be sized so that the splits add up to the container height and width. (To get a split of a fixed width, then, you’d have to introduce a subview of the desired width.)

Then you have to start playing with the holding priorities to control the allocation of widths to splits when the container view changes size. This can be messy, because (AFAICT) you have no choice but to do this by running the app and observing the behavior, and because the behavior is also affected by other autolayout priorities, such as the priority at window resizes affect (or don’t affect) window contents.

it’s frustrating, and you just have to persevere until you get what you want.