On Sat, Jul 11, 2009 at 3:04 PM, Christopher Henrich<[email protected]> 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 protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
