On Feb 6, 2010, at 10:17 PM, Graham Cox wrote: > So you're hard-coding the position of a window based on intimate knowledge of > how your personal system happens to be set up. Presumably you can see why > that might not be a good idea.
Oh, sure: that was just to make the example as closed-form as possible. IRL, it's based on a mouse click (the "window" I'm creating is actually a menu). The point I was trying to make was, if I click in some spots, the net effect is that the menu appears just under the mouse, as expected, but if I click in other screen regions, even just a pixel or two away, behavior becomes very odd. In that regard, it's interesting to note that -[NSMenu popUpMenuPositioningItem:atLocation:inView:] behaves perfectly when passed the mouse location directly. That makes it about a hundred times easier than the approach I presently use, which involves several coordinate transformations between local-screen, whole-screen, and single-window coordinates (which, yes, I've checked again and again, but still might be the culprit, they being so convoluted). But this routine is new for 10.6, and I'm trying to support back to 10.4. > Initially placing windows can be a bit of an art, precisely because the exact > size, number and placement of screens in the real world varies enormously. > It's probably best to place any window initially somewhere guaranteed to > exist, which means asking NSScreen for information about the screens, and > placing the window somewhere valid. Then, allow the user to move it somewhere > else, and remember that location. NSWindow takes care of most of that for > you. You could place the window on the secondary screen initially provided > that you find out a) whether it actually exists and b) where it is, and also > provide a fallback case for when a) is false. Since my placement is based on a mouse click, it seems pretty safe to assume the location exists. > I'm not sure why you're seeing what you're seeing, given that in your case > you have special knowledge that suggests the rect is valid. It might be > something to do with detecting the so-called 'standard' and 'user' states of > the window which are based on being 'close to' the screen's available rect, > for some definition of 'close to'. "For some definition of 'close to'" sure sounds like it might be the behavior I'm seeing, but I'm unfamiliar with "the so-called 'standard' and 'user' states." Can you hint me a bit more on that? -==- Jack Repenning [email protected] Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" _______________________________________________ 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]
