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
