On Apr 23, 2014, at 7:57 PM, Quincey Morris wrote: > On Apr 23, 2014, at 16:58 , Ken Thomases <k...@codeweavers.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
