Re: nsslider subclass not responding to mouseUp:
Re: nsslider subclass not responding to mouseUp:
- Subject: Re: nsslider subclass not responding to mouseUp:
- From: Erik Buck <email@hidden>
- Date: Mon, 5 Jun 2006 13:46:57 -0700 (PDT)
I have commented on the mouse handling implemented in several Cocoa controls before. In fact, the Cocoadev search that mmalcolm provided probably contains my comments.
Just to be redundant, I think mouse handling as suggested in http://developer.apple.com/documentation/Cocoa/Conceptual/BasicEventHandling/index.html
is a terrible way to do it in most cases. I have been fortunate enough to discuss this very issue with several AppKit engineers, but I havent convinced anyone yet ;) The original rationale given back in the NeXT days was that it was a performance optimization. I am sure that is not an issue anymore!
Several people have commented to me that hijacking the "normal" event handling system the way Apple suggests is nice for views like graphical editors where the meaning of a mouseDown:, mouseDragged:, mouseUp: sequence may depend on the state of the view. For example, depending on the state, the mouse operations may be selecting objects or dragging objects or drawing lines, or cropping images, etc. In such cases, it may be nicer to have a big switch statement in mouseDown: to call different methods for mouse tracking based on the view's current state. The idea is that one big switch statement in mouseDown: followed by hijacking the event system avoids big switch statements in all three: mouseDown:, mouseDragged:, and mouseUp:.
However, I have avoided switch statements entirely in my code by having a SEL instance variable that stores the selector to be called when mouse events happen. Whenever the state of the view changes (such as from selection to paint, etc.), I simply update the SEL instance variable. Then I have mouseDown:, mouseDragged:, and mouseUp:. all perform the selector. If the difference between down, up, and drag is important to the mouse tracking logic, just pass an enumerated type along with the event flags and any other interesting data to the method identified by the selector. I have also successfully used handler objects instead of just a selector. In other words, the view has an instance variable that stores the current object that should handle mouse tracking. If the state of the view changes, I just change which object should handle the events
I hope that was clear : ) What I am saying is that in my experience it is always nicer to override all three of mouseDown:, mouseDragged:, and mouseUp: for context sensitive mouse tracking rather than hijacking the "normal" event handling system the way Apple suggests in the provided link.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden