The infrastructure for drawing, printing, and handling events in an app.
SDK
- macOS 10.0+
Framework
- App
Kit
Declaration
class NSView : NSResponder
Overview
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.
frame
returns the location and size of theNSView
object.bounds
returns the internal origin and size of theNSView
object.needs
determines whether theDisplay NSView
object needs to be redrawn.window
returns theNSWindow
object that contains theNSView
object.draw(_:)
draws theNSView
object. (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.
Subclassing Notes
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
). Subclassing 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:
Note
Because NSView
changes the default behavior of the right
method, you should call super
when implementing that method in your custom subclasses.
If your view descends from a class other than NSView
, call super
to let the parent view handle any events that you do not.