Re: Mouse cursors and overlapping sibling NSViews
Re: Mouse cursors and overlapping sibling NSViews
- Subject: Re: Mouse cursors and overlapping sibling NSViews
- From: edward taffel <email@hidden>
- Date: Wed, 23 Apr 2014 22:49:06 -0400
if a control changes rendering on entry, as well as the cursor, mouseEntered is serviceable; if changing the cursor is the goal, cursorUpdate is clearer—better practice. unfortunately, if views overlap mouseMoved is still sent to the parent, which muddles the state directed adjustment anyway.
On Apr 23, 2014, at 8:57 PM, Quincey Morris <email@hidden> 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.
>
> _______________________________________________
>
> 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