Re: NSTableView: move rows through drag and drop?
Re: NSTableView: move rows through drag and drop?
- Subject: Re: NSTableView: move rows through drag and drop?
- From: Quincey Morris <email@hidden>
- Date: Wed, 10 Aug 2011 11:35:11 -0700
On Aug 10, 2011, at 08:12 , Izak van Langevelde wrote:
> On 2011-08-10, at 10:40 AM, Peter Hudson wrote:
>
>> I would do this as follows :-
>>
>> At the same time that you write rows to the pasteboard in the source table, store locally ( perhaps in the source table data source ) the row indexes that were written to the pasteboard.
>> Set observation for a notification ( perhaps the data source for the source table as the observer ) that you will later send indicating that the rows have been moved successfully.
>>
>> At the end of the acceptDrop: ... method in the target table, if the drop is completed, post the notification ( that is observed by the source table data source ) to update its data source by removing the rows you originally wrote to the pasteboard - and update the source table view.
>
>
> Works, but I think it is an awkward solution, as you might as well do without the pasteboard. Also, I'm not sure if this is going to work for inter-application drags, which is not what I'm looking for right now, but I might work on this in the near future.
I *believe* the difficulty is that Mac OS X doesn't really have a UI metaphor for move-dragging between applications -- cross-application drags are by intention copy-drags:
http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/TechnologyGuidelines/TechnologyGuidelines.html#//apple_ref/doc/uid/TP30000355-SW9
Move-dragging is not as simple as it seems because (at least) it may not be reliably undoable -- undoing the drag requires interacting with the undo mechanism in 2 separate applications, and their states may not be compatible at the time of the undo. OTOH, because the move is destructive of data in the source application, if it can't be undoable there really needs to be a user confirmation before it happens, and that complicates the process.
Therefore, if you have a usage case where you can justify using move-drag, solving the UI side of the problem (which probably involves changing both applications) is left for you on your own.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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