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 protected]> wrote: > On Apr 23, 2014, at 16:58 , Ken Thomases <[email protected]> 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 protected]) > > 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/etaffel%40me.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
