Re: Overlay windows

FROM : John C. Randolph
DATE : Mon May 02 14:49:48 2005

On Apr 29, 2005, at 8:24 AM, Ken Tabb wrote:

> Afternoon folks (over here anyway),
>
> I'm about to add an overlay window over my graphics view so as to 
> remove the need to frequently redraw the (expensive) graphics 
> unnecessarily, and I have a few questions that I'd like to ask. 
> I've watched WWDC 2004's Cocoa Tips & Tricks session (411) where 
> they discuss creating an overlay window as a child window of the 
> 'visible' window, but there are some complexities I'd like to know 
> the answer to:
>
> [1] The overlay view needs to stay locked onto (same size / 
> position as) my graphics view. Bearing in mind my graphics window 
> has a toolbar that the user may show / hide mid-app, how do I 
> guarantee that my overlay view fits over my graphics view, and that 
> it does not appear an NSToolBar's height above / below it? Do I 
> just catch the graphicsWindows -windowDidResize notification and 
> update then?


You can do that, or you could tell your graphics view to post frame/
bounds changed notifications, and update your overlay window when you 
get those notifications.  The tricky part would be clipping your 
overlay if your graphics view's selection is clipped by its enclosing 
scrollview.  Doable, certainly, but potentially annoying to sort out ;-)

I should probably update the "Cropped Image" sample to use an overlay 
window.  I didn't use one originally, because overlays were rather 
more work under Jaguar, and I wanted to keep the example simple.

>
> [2] My graphics view is inside a scrollview. Bearing in mind it is 
> the job of the overlay view to draw things (eg. selection handles) 
> over the appropriate objects in the graphics view, it's important 
> that the overlay view respects the scrolled location of the 
> graphics view. So what's the easiest way of tallying the overlay 
> view's scrolled position to the graphics view's scrolled position? 
> Do I even need the overlay view to be in a scrollview, or should I 
> just offset the overlayView's coordinate system relative to the 
> scrolled position of the graphicsView?


Sign up for the frame changed notifications, and adjust your drawing 
as you like... Remember that the coordinate system of your custom 
view is yours to manipulate as you like for your own convenience.

> If notifications wouldn't work in [1] I'm thinking maybe bindings 
> could be used to bind the [[overlayWindow contentView] frame] to 
> [[graphicsWindow contentView] frame], which should allow for a 
> toolbar shifting the graphics window's contentView up / down.



>
> Ditto I was wondering if I could somehow bind the overlayView's 
> frame, bounds and scrolled position to the graphicsView's 
> respective attributes, so that my selection handles appear in the 
> right places (and are only drawn for visible objects etc.)?


That should work..  You'll probably need to write some accessors and 
override -setFrame: and -setBounds: to post the KVO notifications 
yourself, though. Out of the box, NSView doesn't vend any size-
related bindings.

> Stop me if I'm barking up the wrong tree here 8^)


I don't think you are... I did something similar in the CoreData 
"Stickies" example, to get the window frames into my data model.

-jcr


John C. Randolph <<email_removed>> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html