Re: NSTrackingArea strange requirement
Re: NSTrackingArea strange requirement
- Subject: Re: NSTrackingArea strange requirement
- From: Quincey Morris <email@hidden>
- Date: Fri, 28 Nov 2008 09:52:34 -0800
On Nov 28, 2008, at 01:57, rajesh wrote:
On 27/11/2008, at 10:22 PM, rajesh wrote:
but I see a kind of problem with above approach as well.
Since we are updating the TrackingAreas in updateTrackingAreas
(removing and adding track areas) , my cursor (which is set to
"resizeUpDownCursor" mouseEntered: ) seems to flicker when ever
try updating/resizing my view due to the fact that trackAreas are
changed every time.
You shouldn't be using -mouseEntered: to set the cursor. You should
init the tracking area with the NSTrackingCursorUpdate option and
then implement the -cursorUpdate: method.
Sorry my mistake :( . I corrected it. but the cursor still flickers
and I think I am missing some great deal in implementing the tracking.
Given your requirements, there's probably no really easy way for you
to handle the cursor, but I still think you're making it harder for
yourself than it needs to be.
IIRC, you have a parent custom view, which contains subviews that are
instances of NSBox, each of which contains other views, some of which
may set the cursor on their own (like text fields -- let's pretend
they're all text fields for the sake of the discussion).
-- When the mouse is over the parent view, but not over any of the
boxes, you want a "resize" cursor.
-- When the mouse is over a text field, you don't want to interfere.
-- When the mouse is over a box subview, but not over one of the text
fields, you want to .. what? Let the cursor be whatever it was *before
it entered the parent view*? Set the cursor to an arrow?
I suspect you're trying to do the former (let the cursor revert to
whatever it was before you changed to a "resize" cursor), but I think
the correct answer is the latter (set the cursor to an arrow).
One reason I think it's correct is that it's doable, while the other
choice may not be, or not without driving you insane.
So, again, I think you just need one tracking area for the parent
view, and one tracking area for each box view.
-- When the mouse enters a "resize" region, either by entering it from
the outside or by exiting one of the box subviews, your custom view
gets a cursorUpdate event. You should check the mouse location, and
set the appropriate "resize" cursor.
-- When the mouse enters a text field, it changes to whatever the text
field wants it to be.
-- When the mouse enters a box region, the cursorUpdate event will
attempt to go to the view under the mouse -- the box view or one of
its subviews. If that view implements cursorUpdate, that's fine -- the
cursor is handled. If not (the usual case, I suspect), the event goes
up the responder chain till some responder handles it. In this case,
that would be your custom view.
So, your custom view should check the mouse location, and set the
arrow cursor if the mouse is over one of its subviews.
That is, your custom view's cursorUpdate: method is going to be
setting the cursor appropriately for *all* of the tracking area
events, *except* where a sub-subview handles the cursor on its own.
That means it needs to check the mouse location and determine the
appropriate cursor.
Having said all that, I'll add:
-- If you re-define tracking areas (delete the old ones and create new
ones), there's a temporary loss of mouse synchronization -- whether
the mouse is outside or inside becomes "unknown" until at least the
mouse moves, maybe longer. That means you could fail to get expected
cursorUpdate events, possibly until the next time the mouse enters or
exits a tracking area. To minimize the effects of this defect, make
sure you use the NSTrackingAssumeInside option for the tracking areas.
That option is mis-documented, and in most cases it's better to use it
than to not use it. (The correct documentation is in the Leopard
developer release notes.)
-- Although it may not apply here, there's one cause of cursor
flickering that's easy to overlook. When the mouse is inside a scroll
view or any of its subviews, the scroll view itself may sometimes set
the cursor, especially when scrolling. If your custom view is inside a
scroll view, you should invoke -[NSScrollView setDocumentCursor:]
whenever you change the cursor, so that the cursor it uses matches the
cursor you're trying to use.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden