Re: Mouse cursors and overlapping sibling NSViews
Re: Mouse cursors and overlapping sibling NSViews
- Subject: Re: Mouse cursors and overlapping sibling NSViews
- From: Ken Thomases <email@hidden>
- Date: Wed, 23 Apr 2014 20:16:22 -0500
On Apr 23, 2014, at 7:57 PM, Quincey Morris wrote:
> On Apr 23, 2014, at 16:58 , Ken Thomases <email@hidden> wrote:
>
>> If the cursor is appropriate for a given view, that's a *strong* indication to the user that a click will act on that view. So, the view controlling the cursor at a given point should also be the view that receives the click at that point.
>
> Wait, did I miss something? Wasn’t Edward correct in pointing out that using mouseMoved: to set the cursor is not correct, and cursorUpdate: should be used instead (with tracking areas with NSTrackingCursorUpdate) should be used. That mechanism already chooses the correct view to get set the cursor.
I didn't see anybody saying that the cursor was being set in -mouseMoved:. As far as I understood the original issue, it's that the cursor is set via tracking areas and -cursorUpdate: on one view but -mouseMoved: is being called on a different view. Sean wants Cocoa to be consistent about which view is asked to update the cursor and which is told that the mouse has moved.
But I may have misunderstood.
(Of course, the better solution, is seems to me, is to stop using sibling views in a situation that calls for subviews.)
Regards,
Ken
_______________________________________________
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