• Choose a category
• All
• Classic-Fiction

By Root 851 0

The active application forwards the keyboard events to the key window. The key window forwards the event to the “active” view. Which view, then, is the active one? Each window has an outlet called firstResponder that points to one view of that window. That view is the “active” one for that window. For example, when you click on a text field, it becomes the firstResponder of that window (Figure 19.1).

Figure 19.1. The First Responder of the Key Window Is “Active”

When the user tries to change the firstResponder to another view (by tabbing or clicking the other view), the views go through a certain ritual before the firstResponder outlet is changed. First, the view that may become the firstResponder is asked whether it accepts first-responder status. A return of NO means that the view is not interested in keyboard events. For example, you can’t type into a slider, so it refuses to accept first-responder status. If the view does accept first-responder status, the view that is currently the first responder is asked whether it resigns its role as the first responder. If the editing is not done, the view can refuse to give up first-responder status. For example, if the user had not typed in his or her entire phone number, the text field could refuse to resign this status. Finally, the view is told that it is becoming the first responder. Often, this triggers a change in its appearance (Figure 19.2).

Figure 19.2. Becoming the First Responder

Note that each window has its own first responder. Several windows may be open, but only the first responder of the key window gets the keyboard events.

NSResponder

We are interested in the following methods that are inherited from NSResponder:

- (BOOL)acceptsFirstResponder

Overridden by a subclass to return YES if it handles keyboard events.

- (BOOL)resignFirstResponder

Asks whether the receiver is willing to give up first-responder status.

- (BOOL)becomeFirstResponder

Notifies the receiver that it has become first responder in its NSWindow.

- (void)keyDown:(NSEvent *)theEvent

Informs the receiver that the user has pressed a key.

- (void)keyUp:(NSEvent *)theEvent

Informs the receiver that the user has released a key.

- (void)flagsChanged:(NSEvent *)theEvent

Informs the receiver that the user has pressed or released a modifier key (Shift, Control, or so on).

NSEvent

We discussed NSEvent in terms of mouse events in the previous chapter. Here are some of the methods commonly used when getting information about a keyboard event:

- (NSString *)characters

Returns the characters created by the event.

- (BOOL)isARepeat

Returns YES if the key event is a repeat caused by the users holding the key down; returns NO if the key event is new.

- (unsigned short)keyCode

Returns the code for the keyboard key that caused the event.

- (NSUInteger)modifierFlags

Returns an integer bit field indicating the modifier keys in effect for the receiver. For information about what the bits of the integer mean, refer to the discussion in Chapter 18.

Create a New Project with a Custom View

Create a new project of type Cocoa Application. Name it TypingTutor and set the Class Prefix to TypingTutor.

In Xcode, create an Objective-C class that is a subclass of NSView subclass, and name it BigLetterView.

Lay Out the Interface

Open MainMenu.xib and click on the TypingTutor window in the dock to open it. Create an instance of your class by dragging out a Custom View (under Cocoa -> Layout Views) and dropping it onto the window (Figure 19.3).

Figure 19.3. Drop a View onto the Window

In the Identity Inspector, set the class of the view to be BigLetterView (Figure 19.4).

Figure 19.4. Set the Class of the View to BigLetterView

Drop two text fields (under Cocoa -> Controls) onto the window (Figure 19.5).

Figure 19.5. Completed Interface

Make Connections

Now you need to create the loop of key views for your window. That is, you are setting the order in which