gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSCursor mismatched push and pop


From: David Chisnall
Subject: Re: NSCursor mismatched push and pop
Date: Sat, 5 Oct 2013 15:37:28 +0100

On 5 Oct 2013, at 12:53, David Chisnall <address@hidden> wrote:

> http://theravensnest.org/NSCursor.1.log
> 
> This has the event delivered with every sendEvent: message logged, and is 
> showing the mouse-over-text-field-when-window-created-gets-ibeam-cursor-stuck 
> bug.


This one is clearer: http://theravensnest.org/NSCursor.2.log

This shows the bug, in quite a small trace.  push, pop, and set messages are 
logged, with a back trace on every [NSCursor set].  

When the NSCursor class is initialised, it sets an initial arrow cursor, but 
does not push it onto the stack.  

This is then popped in response to an appKitDefined event (subtype 1).  Oddly, 
this actually does set a cursor, even though there have been no -push messages 
before that point and so I'd expect the array to be empty.  This is inside the 
NSTextView's updateState: method (which calls [NSWindow 
invalidateCursorRectsForView:], which calls [NSView discardCursorRects:].

There's then another pop, from the window setting its bounds.

There's then a cursorUpdate event, which triggers a push.  This is called from 
[NSCursor mouseEntered:] and is the one that sets the i-beam cursor.

There's then another push from [NSCursor mouseEntered:], of the i-beam cursor 
again, then again.

Then there's a pop, which restores the i-beam cursor, but is probably intended 
to restore the arrow cursor.

It seems that we are pushing the i-beam cursor too many times and I think 
that's because we're delivering a mouseEntered: event and then another 
mouseEntered: event in sequence.  I'd have expected that we'd get a 
mouseExited: event first (from the old rectangle), and then a mouseEntered: 
event (from the new one), so we'd pop the i-beam and then push it back again.  

Looking at the NSWindow code, it appears that we should be getting the event 
delivery in the right order, as long as _lastPoint actually is the last point 
where we did intersection checking.  It appears that it is set in response to 
some mouse events that don't trigger cursor checking and also in response to a 
-resetCursorRects message.

David



-- Sent from my Cray X1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]