Re: NSTrackingArea strange requirement
Re: NSTrackingArea strange requirement
- Subject: Re: NSTrackingArea strange requirement
- From: rajesh <email@hidden>
- Date: Mon, 1 Dec 2008 10:07:11 +0100
On Nov 28, 2008, at 6:52 PM, Quincey Morris wrote:
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).
Your assumption is right.. I just want the cursor behave as it is
supposed to when it is over subview
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.
this dint occur to me as the problem , but setting the documentCursor
is working great !!! but again there is catch , the lower part of my
subview is filled with textView so while dragging ( the gap between
the subviews , which resizes them ) , its apparent that mouse point
enters the textView ( while still in dragging state) hence flickering
starts over but only the direction in which textView appears .
One observation is flickering frequency is not that insane compared to
the earlier one :)
I am trying to deal this by setting tracking area for each of the
subview , hope this should fix the problem.
Thanks for the valuable input.
_______________________________________________
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
_______________________________________________
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