Ah-ha! This was revealing and disclosed the missing link. Turns out that as
expected, the problem was me doing something stupid. In this case, code in
a totally different source file was taking these values, much farther down
the line, and re-scaling them again. I'd forgotten this old code existed,
On Apr 22, 2014, at 15:36 , Eric Shepherd wrote:
> When the cursor is at the top edge of my window, the Y value is off by 10
> pixels.
>
> When the cursor is at the bottom edge of my window, the Y value is off by 40
> pixels.
As I suggested previously, this could indicate that your view boun
So, here's a weird thing I've just now noticed:
When the cursor is at the top edge of my window, the Y value is off by 10
pixels.
When the cursor is at the bottom edge of my window, the Y value is off by
40 pixels.
What the...?
Eric Shepherd
Gmail: the.she...@gmail.com
Twitter: sheppy
On Tue,
On Apr 21, 2014, at 18:28 , Kyle Sluder wrote:
> Why not?
Let’s assume for the sake of an example, the toolbar is 40 points high, and the
OpenGL view (its visible rect, at least) is 200 points high. According to Eric,
when the cursor is 40 points *above* the bottom of the view, where.y is 200
On Apr 21, 2014, at 8:28 PM, Kyle Sluder wrote:
> On Mon, Apr 21, 2014, at 05:24 PM, Quincey Morris wrote:
>> On Apr 21, 2014, at 17:15 , Eric Shepherd wrote:
>>
>>> I've checked -- [self bounds].origin.y is 0.
>>
>> That can’t be! What is ‘where.y’ at the very top of your view? Can you
>> log
On Mon, Apr 21, 2014 at 8:24 PM, Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:
> That can’t be! What is ‘where.y’ at the very top of your view? Can you log
> self.bounds so we can see all of it?
>
I've flipped my view because I'm dealing with existing code that assumes
that (0,0) i
On Mon, Apr 21, 2014, at 05:24 PM, Quincey Morris wrote:
> On Apr 21, 2014, at 17:15 , Eric Shepherd wrote:
>
> > I've checked -- [self bounds].origin.y is 0.
>
> That can’t be! What is ‘where.y’ at the very top of your view? Can you
> log self.bounds so we can see all of it?
Why not? If it ret
On Apr 21, 2014, at 17:15 , Eric Shepherd wrote:
> I've checked -- [self bounds].origin.y is 0.
That can’t be! What is ‘where.y’ at the very top of your view? Can you log
self.bounds so we can see all of it?
Well, it can be. A couple of other possibilities:
— Your view is larger than you thin
On Mon, Apr 21, 2014 at 7:56 PM, Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:
> And ‘self’ is the NSOpenGLView, yes? It sounds like your view’s bounds
> origin has been moved by the height of the toolbar. Perhaps what you
> *should* be logging (and using) is ‘where.y - self.bounds.
On Apr 21, 2014, at 16:46 , Eric Shepherd wrote:
> where = [self convertPoint:where fromView:nil]; // Convert to the view's
> frame of reference
>
> NSLog(@"Mouse Y: %3.0f", where.y);
And ‘self’ is the NSOpenGLView, yes? It sounds like your view’s bounds origin
has been moved by the hei
On Mon, Apr 21, 2014 at 7:03 PM, Ken Thomases wrote:
> 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.
>
Yeah, that's why I'm so confused. I'
I'm doing this:
- (void)mouseMoved:(NSEvent *)theEvent {
NSPoint where = [theEvent locationInWindow];
where = [self convertPoint:where fromView:nil]; // Convert to the
view's frame of reference
NSLog(@"Mouse Y: %3.0f", where.y);
}
And the results are as described previously. This is the
On Apr 21, 2014, at 15:23 , Eric Shepherd wrote:
> 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.
Are you sure you’re using the correct coordinate
On Apr 21, 2014, at 5:23 PM, Eric Shepherd wrote:
> On Mon, Apr 21, 2014 at 3:43 AM, Quincey Morris
> 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 i
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
I have an NSOpenGL view in a window with a nib-based toolbar that behaves
correctly, so I don't think the OpenGL machinery is completely ignorant of
toolbars.
Noah Desch
>
> That sounds correct, but IIRC the methods that convert between a window’s
> content size and its frame size don’t tak
On Apr 20, 2014, at 23:53 , Graham Cox wrote:
> The toolbar view is actually added as a PEER of the window's content view,
> and the content view is resized to accommodate the toolbar when it is shown
> or hidden.
That sounds correct, but IIRC the methods that convert between a window’s
conte
On 21 Apr 2014, at 6:23 am, Quincey Morris
wrote:
> More generally, though, you might reconsider using a NSToolbar at all. I
> guess the geometry of NSToolbar has always been "neither fish nor fowl" (that
> is, sort of part of the window frame, yet sort of part of the window content)
The to
On Apr 20, 2014, at 2:54 PM, Eric Shepherd wrote:
> On Sat, Apr 19, 2014 at 4:35 AM, Ken Thomases wrote:
>
>> * You already suggested that this will work: try toggling the toolbar to
>> hidden and then showing again.
>
> Now this is crazy: this doesn't work either. What the heck?
I'm starting
Eric Shepherd
Gmail: the.she...@gmail.com
Twitter: sheppy
On Sun, Apr 20, 2014 at 4:23 PM, Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:
> On Apr 20, 2014, at 12:54 , Eric Shepherd wrote:
>
> Nope. :(
>
>
> The only *technical* suggestion I can add — beyond Ken’s excellent
> sugg
On Apr 20, 2014, at 12:54 , Eric Shepherd wrote:
> Nope. :(
The only *technical* suggestion I can add — beyond Ken’s excellent suggestions
— is to move the OpenGL view down a level. That is, assuming it’s a subview of
the window’s content view, make it a subview of a custom view that is a subv
On Sat, Apr 19, 2014 at 4:35 AM, Ken Thomases wrote:
> * Try calling -frameRectForContentRect: to see if that forces the window
> to recompute how its frame is affected by the toolbar.
>
Nope. :(
>
> * Try setting the window's style mask with -setStyleMask:. I know from
> past experience that
On Apr 19, 2014, at 1:30 AM, Eric Shepherd wrote:
> I only add the toolbar once; after that it's toggling visibility status.
> I'm just initially adding the toolbar programmatically instead of in the
> nib because I ran into some problems doing that in my Cocoa/Carbon hybrid
> app.
Some more poss
invalidateShadow: was a nice idea; just tried it and it didn't help.
I only add the toolbar once; after that it's toggling visibility status.
I'm just initially adding the toolbar programmatically instead of in the
nib because I ran into some problems doing that in my Cocoa/Carbon hybrid
app.
Onc
On Apr 19, 2014, at 12:52 AM, Eric Shepherd wrote:
> On Thu, Apr 17, 2014 at 8:55 AM, Eric Shepherd wrote:
>
>> I'm having an odd problem with my Mac OS X application here. I have a
>> window containing an NSOpenGLView, into which I programmatically insert a
>> toolbar when the window is opened.
Still stumped by this one. I've read about every method that has "resize"
or "toolbar" in its name, among others, without finding anything. :)
Eric Shepherd
Gmail: the.she...@gmail.com
Twitter: sheppy
On Thu, Apr 17, 2014 at 8:55 AM, Eric Shepherd wrote:
> I'm having an odd problem with my Mac
I'm having an odd problem with my Mac OS X application here. I have a
window containing an NSOpenGLView, into which I programmatically insert a
toolbar when the window is opened.
Upon doing so, I find that as I move the mouse down through my window, it
turns into the "resize cursor" quite some dis
27 matches
Mail list logo
