3.4 Controls

The most visible aspects of an application are the controls that users interact with. In Cocoa, control objects such as buttons, tables, sliders, and text fields all have a common parent class: NSControl, which is itself a subclass of NSView. Figures Figure 3-6 and 3-7 show the class hierarchies for NSCell and NSControl, and Table 3-1 describes the control classes implemented in the Application Kit.

Figure 3-6. NSControl class hierarchy

In general, a Cocoa control must have the ability to do several things:

• Draw itself on the screen.

• Respond to basic events such as a mouseclick or a drag.

• Send action messages to arbitrary objects in response to events.

NSControl gives some amount of control over when and how a control sends the action message to its target. Specifically, you can specify whether the action is to be sent only after the user has finished clicking the control (i.e., when the mouse button is raised), or if the action is to be sent continuously while the mouse button is depressed. You can set this behavior either in Interface Builder or by using the method setContinuous:.

3.4.1 Cells

Most AppKit controls have associated cell classes, and in those cases the cell implements all drawing and event handling, while the control serves as a container within which the cell is drawn. A cursory comparison of NSCell to NSControl makes it appear as though these classes unnecessarily duplicate each other's behavior (see Figure 3-7). For example, both classes declare methods such as intValue, floatValue, doubleValue, stringValue, alignment, and font. The impression is strengthened when considering NSCell's responsibility for drawing many Application Kit controls, and that it takes over other similar roles you would expect from an NSControl. To understand the division of labor between cells and controls, consider the issues of performance and flexibility.

Figure 3-7. NSCellclass hierarchy

Because NSControl is a subclass of NSView, it comes with a lot of baggage (inherited instance variables and data structures) that take memory. As a result, the performance of an application can degrade as the number of NSView instances in an interface increases. NSCell, however, is a much more lightweight object.

Consider now the class NSMatrix. NSMatrix is a subclass of NSControl that manages a rectangular array of NSCells. It is often used in situations when several similar controls are needed, such as for the keypad in the Calculator application, or in a spreadsheet. Consider the case of a 10-column by 10-row spreadsheet. Implementing such a spreadsheet with text views would require 100 instances of NSTextField. However, if you were to build a spreadsheet with an NSMatrix you would have just one instance of an NSView subclass and 100 instances of NSTextFieldCell, a decidedly lighter-weight class than NSTextField. Moreover, when drawing the matrix, there is just a single graphics context switch (as opposed to one context switch per view). You can see the advantage of using cells over views as the size of the spreadsheet increases.

Cells also facilitate the creation of composite controls that are composed of many different parts, such as table or browser views. NSTableView, for example, draws the contents of table columns with NSTextFieldCells. This can be changed to display the contents of a column using NSComboBoxCell or NSButtonCell.

Table 3-1 summarizes the various Application Kit control and cell classes.

NSControl

NSCell

NSBrowser

NSBrowserCell

NSButton

NSButtonCell

NSPopUpButton

NSPopUpButtonCell

NSColorWell

NSImageView

NSImageCell

NSMatrix

NSForm

NSFormCell

NSScroller

NSSlider

NSSliderCell

NSTableView

NSOutlineView

NSStepper

NSStepperCell

NSTextField

NSTextFieldCell

NSComboBox

NSComboBoxCell

NSSecureTextField

NSSecureTextFieldCell