Re: Really confused about "bounds" and "frames".
Re: Really confused about "bounds" and "frames".
- Subject: Re: Really confused about "bounds" and "frames".
- From: Brock Brandenberg <email@hidden>
- Date: Sat, 14 Jun 2003 12:40:49 -0500
Hi Jim.
>
In a Nib file I have constructed a window which contains a
>
scrolled view, call it MyView. The dimensions of the view (as
>
specified in the nib file) are about twice the size of the window. In
>
MyView.m I use the method -scrollPoint:(NSPoint)p to set the center
>
of the view in the center of the window, which nicely centers the
>
scrollers.
>
I would like to find the NSRect of that part of MyView which
>
shows in the window, regardless of the position of the scrollers or
>
of the size of the window.
>
I have studied the documentation at great length and perused
>
all the methods of NSWindow and NSView that might yield the desired
>
info. Under NSWindow I have tried -contentView:(NSView)view and
>
-frame; under NSView I have tried -bounds, and -frame. All of these
>
methods seem to give me the same information, namely the size of the
>
view as specified in the nib file, no matter how I adjust the
>
scrollers or the size of the window.
>
So, how can I get the dimensions of just that part of MyView
>
shown in the window. I would like to get an NSRect referenced to
>
MyView.
There are a couple basic principles to the view hierarchy that should help
it make more sense to you.
The first principle is that views have off-screen dimensions, the "bounds",
and on-screen dimensions, the "frame". It's the positions and ratio between
these two that determines what gets copied onto the screen from the actual,
off-screen view data. Changing the position of the bounds rect but leaving
the frame rect constant would make the image appear to pan around the frame
rect. Changing the size of the bounds rect but leaving the frame rect
constant would make the image appear to zoom in or out in the frame rect.
These are very general visualizations, but you should get the basic point.
The second principle is that there is a view containment hierarchy that
positions subviews inside of superviews. It's this mechanism that's likely
causing your confusion. Some superviews can clip their subviews so that you
don't see all of the subview's frame rect on-screen, the NSScrollView being
an example of such a superview. The result is that the subview still has a
frame rect of the size you specify, but only a portion of it is visible at
any one time, the portion that the NSScrollView deems appropriate to show.
The NSScrollView bases it's scroll bar positions on how much of the
subview's frame rect is visible, and you only see the clipped portion of the
subview's frame rect that the NSScrollView needs to show. As you scroll
around the NSScrollView, the subview's frame rect remains the same size and
it's the scroll view's clip rect that's changing. It's as though your
panning the subview's frame rect around behind the clip rect of the scroll
view.
Now with these principles in mind, you can see how the superviews will
determine the portion of your subview that's actually visible. Look at an
NSScrollView and the way that it's constructed. It has NSScrollers and an
NSClipView as part of it, so it's the job of the NSClipView to clip the
frame rect of your subview. To clarify methods, the NSClipView is the
contentView of the NSScrollView. Your subview is the documentView of the
NSClipView and NSScrollView. So, in principle, you just have to look up
through the view hierarchy to get the unclipped, visible portion of your
subview (that has little relation to either its bounds or frame rect, except
for its limits). There are a number of ways to do this, the easiest of which
is the visibleRect convenience method in NSView that gets you the portion of
your view not clipped by its superviews. You can also walk up the view
hierarchy with [NSView superview] to get your subview's NSClipView superview
and ask it for its documentVisibleRect. Or you can walk all the way up to
the NSScrollView and ask it for its documentVisibleRect. In simple window
hierarchies (as long as you don't have scroll views inside of scroll views),
these methods should all result in the same values. As long as you
understand the hierarchy though, you can use the superviews to get the
information that you need no matter how complex the view hierarchy.
Brock Brandenberg
----- industrial design @ www.bergdesign.com ------
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.