|
The Window class defines objects that manage and coordinate the windows that an application displays on the screen. A single Window object corresponds to, at most, one window. The two principle functions of a Window are to provide an area in which Views can be placed, and to accept and distribute, to the appropriate Views, events that the user instigates through actions on the mouse and keyboard.
Rectangles, Views, and the View Hierarchy
A Window is defined by a frame rectangle that encloses the entire window, including its title bar, resize bar, and border, and by a content rectangle that encloses just its content area. Both rectangles are specified in the screen coordinate system. The frame rectangle establishes the Window's base coordinate system. This coordinate system is always aligned with and is measured in the same increments as the screen coordinate system (in other words, the base coordinate system can't be rotated or scaled). The origin of a base coordinate system is the bottom left corner of the Window's frame rectangle.
You create a Window (through one of the init:... methods) by specifying, among other attributes, the size and location of its content rectangle. The frame rectangle is derived from the dimensions of the content rectangle.
When it's created, a Window automatically creates two Views: an opaque frame view that fills the frame rectangle and draws the border, title bar, resize bar, and background, and a transparent content view that fills the content area. The frame view is a private object that your application can't access directly. The content view is the "highest" accessible View in the Window; you can replace the content view with a View of your own creation through Window's setContentView: method.
You add other Views to the Window by declaring each to be a subview of the content view, or a subview of one of the content view's subviews, and so on, through View's addSubview: method. This tree of Views is called the Window's view hierarchy. When a Window is told to display itself, it does so by sending View-displaying messages to each object in its view hierarchy. Because displaying is carried out in a determined order, the content view (which is drawn first) may be wholly or partially obscured by its subviews, and these subviews may be obscured by their subviews (and so on).
Event Handling
Mouse and keyboard events that are directed at a Window are automatically forwarded to the object, however, a Window receives keyboard events only if it's the key window. If the event affects the Window directly--resizing or moving it, for example--the Window performs the appropriate operation itself and sends messages to its delegate informing it of its intentions, thus allowing your application to intercede. Events that are directed at specific Views within the Window are forwarded by the Window to the View.
The Window keeps track of the object that was last selected to handle keyboard events as its first responder. The first responder is typically the View that displays the current selection. In addition to keyboard events, the first responder is sent action messages that have a user-selected target (a nil target in program code). The Window continually updates the first responder in response to the user's mouse actions.
Each Window provides a field editor, a Text object that handles small-scale text-editing chores. The field editor can be used by the Window's first responder to edit the text that it displays. The getFieldEditor:for: method returns a Window's field editor. |
unsigned int style:4;
init
mouseDown:(NXEvent *)theEvent