Re: NSTableView and dragging cursor
Re: NSTableView and dragging cursor
- Subject: Re: NSTableView and dragging cursor
- From: Shawn Erickson <email@hidden>
- Date: Sat, 12 Nov 2005 14:01:19 -0800
On Nov 12, 2005, at 12:54 PM, Ken Victor wrote:
first off, i made a "copy and paste typo" in my previous email, i
was NOT doing:
BOOL isCopy = (([info draggingSourceOperationMask] ==
NSDragOperationCopy) != 0);
what i was doing (as many have pointed out i should have been
doing) was:
BOOL isCopy = (([info draggingSourceOperationMask] ==
NSDragOperationCopy) != 0);
Looks like you hit another "copy and paste" error in the above :)
and in fact, this wasn't working. upon further investigation, i
believe i now know what is/was happening (as this should have
worked)! in my tableview's draggingSourceOperationMaskForLocal, i
return:
NSDragOperationCopy | NSDragOperationDelete | NSDragOperationMove
in the tableview's data source
tableView:validateDrop:proposedRow:proposedDropOperation:
if the option key is not pressed, then the passed in draggingInfo's
draggingSourceOperationMask is set to what it was set to by the
table, ie,
NSDragOperationCopy | NSDragOperationDelete | NSDragOperationMove
however, if the option key is pressed, then in
tableView:validateDrop:proposedRow:proposedDropOperation: it is
NSDragOperationCopy
thus, treating it as a bitfield and masking it was not working, as
it always appeared to be a copy!
i'm not sure if this is an implementation bug or a document bug...
but i'm pretty sure this is a bug somewhere! :-)
Not sure it really is a bug given that you are in the "validate" method.
This method is about validating and deciding what is possible for the
current drag target (tableView + row + operation) which then gets
visually reported back to the user (mouse cursor badge changes as
needed based on what you respond with).
You are stating that when an item is dragged from your table the user
can copy, delete, or move what they are dragging. When it comes back
to your table as a drop validation without any modification by the
user (no option key down) then any of the original options need to be
considered as being possible. Your validation should then pick the
operation (out of the source allowed options) that you will do based
on what makes sense for the target of the drop.
In other words copy, move, and delete have been allow by the source
and the user hasn't stated a preference by holding down any modifier
keys so you (your table view acting as a target of a drop) can decide
which of the source allowed operation you want to do. You could
always copy if copy is allowed by the source or could always move if
move is allowed by the source, prefer a move before a copy, or a copy
before a move, etc. You get to chose and when you return the users
mouse cursor will updated to reflect which operation you plan to do.
The user could at this point release the mouse button (finish the
drop), hold down the option key, release the option key, abort the
drag, etc.
When the user holds down the option key they are stating what they
prefer to be done is other then the default which has the affect of
restricting what the source originally allowed (or even what the drop
target stated it would).
Not sure I explained that very well...
-Shawn
_______________________________________________
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