Re: NSScrollView
Re: NSScrollView
- Subject: Re: NSScrollView
- From: Kyle Sluder <email@hidden>
- Date: Sat, 11 Jul 2009 15:38:46 -0700
On Sat, Jul 11, 2009 at 3:04 PM, Christopher
Henrich<email@hidden> wrote:
> Based on the section How Scroll Views Work, I surmise that the scroll view
> uses the frame rectangle to determine the size of the document view. Have I
> got this right?
Not quite. You might want to review the View Programming Guide.
Every view (excepting layer-backed views) has two rectangles: a frame
rectangle and a bounds rectangle. The frame rectangle describes the
view's dimensions in its superview's bounds space. To illustrate,
let's start at the window's content view, since it's the topmost view
in a window's view hierarchy (that you know about, at least) and
therefore we don't have a superview to worry about. The content
view's bounds define a coordinate system; by default this coordinate
system has an origin at the lower-left corner of the view, and has the
upper-right corner defined at some (x0, y0).
Say we put an NSScrollView in the window, offset from the edges by 7
points and with a size of (200, 400). We're actually inserting this
scroll view into the view hierarchy as a subview of the content view.
It has a frame rect of ((7, 7), (x0 - 200 - 14, y0 - 400, 14)).
Hopefully you can see how we arrive at the dimensions of the view,
based on the superview's size, the scroll view's size, and the margins
we've maintained.
This scroll view has a bounds coordinate system, too. The bounds
rectangle defines a coordinate space such that the lower left corner
is at (0, 0), and its upper right corner is at (186, 386). So
essentially what we've done is just apply a translation operation to
the coordinate space in which the frame rectangle lives. We can apply
a different translation or even a scaling transformation by playing
around with the definition of the bounds rectangle. At draw time, the
drawing mechanism takes care of all the math required to convert
between coordinate spaces.
Hopefully that makes sense, because the world inside scroll views is a
bit more complicated. Scroll views have a number of subviews: the
scrollers, the corner view, the header view, and most importantly an
NSClipView known as the content view. The clip view is where the
magic happens. The clip view has a subview called the document view:
this is what you're thinking of when you stick something in a scroll
view. Often times it's something like an NSTableView, NSOutlineView,
or an instance of some MyDocumentView class.
The reason there's a clip view in between the scroll view and the
document view has to do with the bounds rectangle i described above.
When you change a document's frame, or bounds, it sends an
NSViewFrameDidChangeNotification or NSViewBoundsDidChangeNotification
to the default NSNotificationCenter. The clip view listens for these
notifications from its document view, and sets up its own bounds so
that only the appropriate portion of the document is visible inside
the scroll view. The clip view's frame never changes: it always lives
in the same spot inside the scroll view's bounds coordinate space.
But because it keeps abreast of its document view's frame changes, it
can fuddle with its own bounds in order to set up the coordinate space
in a way that causes your document view to be none the wiser.
HTH,
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >NSScrollView (From: Christopher Henrich <email@hidden>) |