The infrastructure for drawing, printing, and handling events in an app.
- macOS 10.0+
You typically don’t use
NSView objects directly. Instead, you use objects whose classes descend from
NSView or you subclass
NSView yourself and override its methods to implement the behavior you need. An instance of the
NSView class (or one of its subclasses) is commonly known as a view object, or simply as a view.
Views handle the presentation and interaction with your app’s visible content. You arrange one or more views inside an
NSWindow object, which acts as a wrapper for your content. A view object defines a rectangular region for drawing and receiving mouse events. Views handle other chores as well, including the dragging of icons and working with the
NSScroll class to support efficient scrolling.
Most of the functionality of the
NSView class is automatically invoked by AppKit. Unless you’re implementing a concrete subclass of
NSView or working intimately with the content of the view hierarchy at runtime, you don’t need to know much about this class’s interface. For any view, there are many methods that you can use as-is. The following methods are commonly used.
framereturns the location and size of the
boundsreturns the internal origin and size of the
needsdetermines whether the
NSViewobject needs to be redrawn.
NSViewobject. (All subclasses must implement this method, but it’s rarely invoked explicitly.)
For more information on how
NSView instances handle event and action messages, see Cocoa Event Handling Guide. For more information on displaying tooltips and contextual menus, see Displaying Contextual Menus and Managing Tooltips.
NSView is perhaps the most important class in AppKit when it comes to subclassing and inheritance. Most user-interface objects you see in a Cocoa application are objects that inherit from
NSView. If you want to create an object that draws itself in a special way, or that responds to mouse clicks in a special way, you would create a custom subclass of
NSView (or of a class that inherits from
NSView is such a common and important procedure that several technical documents describe how to both draw in custom subclasses and respond to events in custom subclasses. See Cocoa Drawing Guide and Cocoa Event Handling Guide (especially "Handling Mouse Events" and "Mouse Events").
Handling Events in Your Subclass
If you subclass
NSView directly and handle specific types of events, the implementation of your event-related methods should generally not call
super. Views inherit their event-handling capabilities from their
NSResponder parent class. The default behavior for responders is to pass events up the responder chain, which is not the behavior you typically want if you handle events in a custom view. Therefore, you should not call
super if your view implements any of the following methods and handles the event:
If your view descends from a class other than
super to let the parent view handle any events that you do not.