I have only had the reverse problem (in some cases I need to circumvent AppKit mechanism), but have you looked at [NSWindow constrainFrameRect:frameRect toScreen:screen]: http://developer.apple.com/mac/library/documentation/cocoa/reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWindow/constrainFrameRect:toScreen:
Jesper On May 15, 2010, at 8:39 AM, Philip White wrote: > Hello, > I was hoping someone could offer me some suggestions: Here is what I'm > trying to do. > I have a window that I create with the NSBorderlessWindowMask flag set. Since > windows with this flag set don't really adopt any of the cocoa movement, > sizing, or constraining behavior, I've been forced to reimplement this > myself. The only real problem has been the constraining behavior (keeping > titlebars on screen, not behind the menubar, etc). I've developed a decent > approximation of Cocoa's behavior but I keep on finding shortcomings in this > behavior when there a multiple screens arranged in unusual ways. > > So I came up with what I though was a bright idea. I'd keep a dummy window, a > normal titled, bordered window, and use it to test window positions and > shapes for validity. Of course that window has to be ordered-out so the user > is unaware of it. So the problem is, while ordered-out windows are subject to > the same constraints as ordered-in windows, those constraints seemed to be > applied lazily. So if you use NSWindow's setFrameOrigin: to set an ordered-in > window's position to something invalid, that position will be corrected > immediately. But for an ordered-out window it will be corrected sometime > later in the run loop. I've tried various schemes for deferring checking of > the dummy window's position (notifications using NSPostWhenIdle, etc.) but I > can't get consistent behavior. > > Is there a way force a window to immediately do its constraint checks? I've > poked around with FScript trying to figure something out but no luck yet. > > Many thanks in advance, > Philip White > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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/jsbache%40adobe.com > > This email sent to jsba...@adobe.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
