This chapter is from the book
This chapter is from the book
This chapter is from the book
6.3 Sizing
At this point, the layout of the window is almost done. Why "almost"? Pull down the File menu and select Test Interface (or press command–R). Your window now "goes live," using the components you put into it. There's nothing behind them, but you can click the buttons and work the other controls.
Now try resizing the window. The contents of the window ride the lower–left corner, sliding into and out of view as the window resizes (Figure 6.6). This is not what we want. Near the right end of your menu bar is an icon resembling an old-fashioned double–throw electrical switch. Click this icon to exit the interface–testing mode. None of the changes you made during testing are permanent.
)
Figure 6.6 As supplied, Cocoa controls do not automatically size and position themselves in a window as the window resizes. You have to specify sizing and positioning behavior yourself.
Cocoa views can be set to resize or simply to stay put as their containers change size and shape. Click the Add button in the window we're constructing to select it. If the Inspector panel is not showing, select Show Inspector (or press command-shift-I) from the Tools menu. In the pop-up menu at the top of the Inspector window, select the third item, Size. (Note that you can bring the Inspector forward with the Size panel visible by pressing command–3.)
The Size panel (Figure 6.7) is dominated by a diagram showing the behavior of the selected view when its enclosing view is resized. The square inside the diagram represents the view itself. The various lines in the diagram switch between "struts" (straight lines) and "springs" (curling lines) when you click them. A view whose inner box contains rigid struts in both directions does not resize; if it has a spring in either direction or both, it can resize in that direction.
)
Figure 6.7 The Size Inspector for a view that should stay put, relative to the top left of its enclosing view. The inside struts are all straight, meaning that it never resizes. The outside struts below and to the right are springy, meaning that they don't influence the view's placement.
When the outer lines are struts, the view will try to maintain the same distance from the corresponding edge of the container. (If both lines are struts and the view isn't resizable, lower and left wins over upper and right, which is why the contents of our window "rode" the lower–left corner out of sight when you resized the window.) If an outer line is a spring and the view is not resizable in that direction, the view will ignore the movement of that edge of the container. If the view is resizable and an outer line is a spring, the view will resize to a degree proportional to its position in the window. Two side-by-side views that obey this rule will maintain their respective shares of the window when it is resized and will not run into each other.
We reexamine the views in the window with an eye to how they should behave when the window resizes. The buttons should never resize and should stay where they are relative to the nearest corner—top left for Add and Remove, top right for Compute. Select each in turn, making Size Inspector for the Add and Remove buttons look like the one in Figure 6.7 and for the Compute button, like Figure 6.8.
)
Figure 6.8 This view maintains its position relative to the top right of its enclosing view. The outside struts to the top and right are rigid.
How do we want the form at the right of the window to behave? We certainly don't want it to shrink or stretch vertically with the window, but we wouldn't mind its growing if the window were to get wider. So the vertical internal strut should be rigid, and the horizontal strut should be springy. We want it to keep its position near the right edge of the window, so the right strut remains rigid. We also want it to stay an inch or so below the title bar, so the top strut is rigid. The bottom strut becomes a spring, allowing the form to float free of that edge. The left strut also becomes a spring, indicating that the form will expand to take a share of the window rather than maintain a rigid margin from the left edge. See Figure 6.9.
)
Figure 6.9 The resizing specification for the form at the right side of the window. We don't want it to stretch vertically, so the inside vertical strut is straight. It would be nice if this view could take advantage of more room horizontally, so its inside horizontal strut is springy, allowing resizing in that direction. It is strictly bound to the top and the right side of the surrounding view. Being resizable horizontally and loosely bound to the left, this view will resize itself proportionately as the window resizes.
The data table should be freest of all, widening with the window and also growing vertically to show more points if the window grows. Both internal struts should be turned into springs. We anchor the view to the top left of the window by leaving those outer struts rigid; we also leave the bottom strut rigid. That way, when the window gets taller or shorter, the table will keep a constant distance of 20 pixels from the bottom of the window. The right-horizontal strut is made springy, so the table view will grow horizontally only to maintain its share of the horizontal space. See Figure 6.10.
)
Figure 6.10 The resizing specification for the scroll view enclosing the data table. It resizes in both directions along with the window. It is strictly bound to the top, left, and bottom edges of its enclosing view, so it will resize to maintain its present distance from those edges; it is loosely bound to the right, so it will take only a proportionate share of growth in that direction.
Now press command-R to try out the window. Now resizing does not shove views out the window. You may want to experiment with other sizing options and see their effects. Remember, you can exit the interface test mode by clicking the switch icon in the menu bar.