On Apr 21, 2014, at 5:23 PM, Eric Shepherd wrote: > On Mon, Apr 21, 2014 at 3:43 AM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > >> … IIRC the methods that convert between a window’s >> content size and its frame size don’t take the toolbar into account, which >> means that they work with a "content size” that isn’t actually the content >> *view* size, and correcting the calculation requires the assumption of >> extrinsic information.
That shouldn't be. I haven't confirmed empirically, but the docs for -[NSWindow contentRectForFrameRect:] and -frameRectForContentRect: are quite explicit that they *do* take the toolbar into account and that's how they differ from the +contentRectForFrameRect:styleMask: and +frameRectForContentRect:styleMask: class methods. >> It strikes me as plausible that an OpenGL view might >> need to make such a conversion, and that it was never implemented to deal >> with the presence of a toolbar. > > I think this is the problem. I added code to dump the Y-coordinate of my > mouse while I move it around in the NSOpenGLView, and sure enough, it's > reaching the value that should be the bottom edge well above the bottom. > The same happens at the top, where the mouse reaches the edge of the view > but the Y value is not what it should be at the edge. This sounds like a symptom of the same issue that's causing the strange cursor behavior, but I very much doubt that the NSOpenGLView can be responsible for either. In case you missed it, Noah Desch reported no problems using an NSOpenGLView in a window with a toolbar. I'm pretty sure some Apple sample projects use NSOpenGLViews in windows with toolbars, too. > Is there a responsible way to get the current height of the toolbar so I > can use that to adjust the calculations here? Apple documents the technique in Toolbar Programming Topics for Cocoa: Techniques for Toolbar Management – Calculating a Toolbar’s Height: <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Toolbars/Tasks/DeterminingOverflow.html#//apple_ref/doc/uid/20000859-SW2>. The technique relies on the fact that +contentRectForFrameRect:styleMask: does *not* take the toolbar into account but the content view's frame does. In your case, I bet the latter assumption is broken just like everything else. Did you see my recent question as to whether you're using a custom subclass of NSWindow that might accidentally override important properties inherited from NSWindow? I didn't see an answer. Regards, Ken _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
