Re: NSTrackingArea strange requirement
Re: NSTrackingArea strange requirement
- Subject: Re: NSTrackingArea strange requirement
- From: chaitanya pandit <email@hidden>
- Date: Sun, 30 Nov 2008 13:20:20 +0530
Hi,
I dunno if this is the right way to do it, but what if you Override
mouseMoved: for the main view that contains all the subviews, and use
a hitTest: to find the view over which the cursor is hovering and
simply use
[[NSCursor whateverCursor] set]; to change the cursor depending on the
view.
You obviously need to call setAcceptsMouseMovedEvennts on the view's
window during initialization so that u'll get called with mouseMoved:.
Just a wild guess,
Chaitanya
On 28-Nov-08, at 11:22 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).
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
_______________________________________________
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