Re: mouseDragged event
Re: mouseDragged event
- Subject: Re: mouseDragged event
- From: James DiPalma <email@hidden>
- Date: Wed, 23 Jun 2004 21:17:32 -0700
On Jun 22, 2004, at 10:35 PM, Nick Zitzmann wrote:
On Jun 22, 2004, at 8:58 PM, James DiPalma wrote:
I have a mouseDown: that does little if an event might start a drag
(all mouse events unless a modifier flag exists) and calls [super
mouseDown:] otherwise. This technique worked, but it was a challenge
to get right especially since mouseUp: needs to be overridden to
handle what NSMatrix would have done if it handled a mouseDown: that
did not start a drag.
I've been able to break NSMatrix's mouse tracking with a minimum of
hacking, and without overriding -mouseUp:.
Another member of our club!
Overriding NSMatrix's mouseDown: and mouseUp: was not a lot of code,
but I found it difficult to get right. We have Finder as our only
example of a dragable browser, drag behavior in table views, and
various historical drag behavior to look at when trying to decide how a
dragable matrix should behave.
Finder does not select on mouse down when it could initiate a drag
(unmodified mouse down on text or icon), but will select on all other
mouse downs. NSTableView selects on shift mouse down, not on
command/apple mouse down, and not on a normal mouse down (which could
initiate a drag).
Its been 2-3 years since I looked at this code, so I'm a little unclear
why I did things. Here are some comments:
I don't have any sample code on me right now (you can probably find
some in the archives), but here's what I did in a NSMatrix subclass'
-mouseDown: method...
1. If the Shift or Command keys were held down when the event
occurred, then it's OK to just send the message to the superclass and
return. It's the easiest way of handling modifier-clicks on cells and
doesn't break anything.
I also check for control key and help key not that I have a help key on
any of my keyboards, I just thought this modifier flag should be
handled by super.
2. Call -getRow:column:forPoint: and save the results for the next
step. If that method returns YES, then the user clicked on a cell. If
it returns NO, then send the event to the superclass.
Hmm. I don't check for getRow's return value; I'll need to do some
testing and bug fixing.
3. Select the row & column in the usual way.
I do not select cells during mouseDown:, which is why I am implementing
mouseUp:.
4. Check the click count. If only one click was in the event, then
trigger the matrix's single-click action. If the button was clicked
two or more times, then trigger the matrix's double-click action.
NSButton sends its action on mouseUp, does it send its double action on
mouseUp: as well? Anyway, since I am implementing mouseUp:, my drag
matrix actions are sent during mouse up.
Also, a matrix might want to allow editing of cells similar to how
NSTableView (double click) or Finder (single click on a single selected
cell) allow editing.
mouseDragged: could end up getting really complicated if you also want
to add behavior like NSTableView's verticalMotionCanBeginDrag.
-jim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.