Re: Unresponsive mouseMoved method
Re: Unresponsive mouseMoved method
- Subject: Re: Unresponsive mouseMoved method
- From: Bob Smith <email@hidden>
- Date: Thu, 29 Mar 2007 14:40:53 -0700
Shawn's suggestion of using tracking rectangles seems like one to
consider. You would not have to use -mouseMoved at all in that
case. The view would get -mouseEntered and -mouseExited regardless
of whether it is first responder, and if you need to know the precise
position of the mouse as it moves within the view, you can start a
timer in -mouseEntered and track the mouse on the timer fires with -
mouseLocationOutsideOfEventStream to the window.
The problem with your category approach is that NSView is not a
concrete class, it is an abstract superclass meaning it might be
implemented in appkit as a class cluster. The behavior of those
isn't quite what you would expect regarding such things as
categories; I believe (someone more knowledgeable correct me if I'm
wrong) applying a category to the abstract parent of a class cluster
in effect applies that category to all of the concrete classes in the
cluster. So you might inadvertently override -mouseMoved in other
view classes that you don't want to mess with.
Hope this helps!
Bob S.
On Mar 29, 2007, at 2:22 AM, Steve Bryan wrote:
The goal is to be able to track cursor position in one particular
subview
and provide feedback regardless of which subview is the current
target. If I
limited the solution to a mouseMoved method for just that subview
then the
user would have to click that subview to get cursor tracking to work.
I agree that adding a method to NSView is less than ideal but this
is for a
specific project, not a general modification that would be used
elsewhere.
In any case how would my definition of mouseMoved in a category for
NSView
hide a different definition in a subclass? Wouldn't it be overridden?
The pitfall that I do see is that if another window in this project
has
setAcceptsMouseMovedEvents set to YES (it is NO by default) and the
window's
delegate has a mouseMoved method then it is going to be called
whenever the
mouse is over any view in the window.
In any case the explanation about the mouse events not following the
responder chain sounds unlike actions sounds correct. Thanks.
On 3/28/07, Bob Smith <email@hidden> wrote:
You are right if his category is on NSView, that is a Bad Idea! I
didn't read carefully and just assumed he had a view subclass. So I
retract my approval...
To the OP, if you provide more detail about what you are trying to
accomplish perhaps other suggestions can be offerred; otherwise
subclassing NSView would be the recommended way to handle the
situation.
Bob S.
On Mar 28, 2007, at 6:05 PM, Shawn Erickson wrote:
> On 3/28/07, Bob Smith <email@hidden> wrote:
>> The window delegate cannot handle mouse events because those do
not
>> follow the responder chain as do actions; mouse events are sent by
>> the window to the view in which the event occurred, and nowhere
>> else. You have done the correct thing by extending your view
class,
>> and I don't see anything wrong with your solution.
>
> Actually he didn't extend his view class he made _all_ NSView
objects
> implement mouseMoved: via a category *cringe*. This possibly will
> break existing NSView objects by possibly hiding their real
> implementation of mouseMoved: and/or causes unrelated views to
message
> window delegates (say a window delegate implements moveMoved: for
> unrelated reasons). So I would say his solution isn't really a good
> one.
>
> It isn't clear to me exactly what he is trying to achieve at a
> high-level... maybe a better way exists that doesn't involve a
window
> delegate handling mouse moved events from views contained in the
> window... sounds like tracking rects may possibly fill the need?
>
> - Shawn
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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)
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)
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