Promised file drag/drop catch 22?
Promised file drag/drop catch 22?
- Subject: Promised file drag/drop catch 22?
- From: Tim Hewett <email@hidden>
- Date: Sat, 1 May 2004 13:19:06 +0100
Hi,
I'm currently enhancing my app which involves having two table views
when previously there was one. The old version allows files and folders
to be dragged from the Finder to the table view, which use the standard
NSTable delegate validateDrop: and acceptDrop: mechanisms (since
drags from the Finder are not HFS promised ones). However it can also
drag a row from its table view to the Finder, and this involves a HFS
promised file drag - thus it implements the mechanism involving the
namesOfPromisedFilesDroppedAtDesintation: selector being implemented
in a subclass of NSTableView.
The new second table view will also have this functionality (i.e. normal
drag/drop from Finder to view, promised file drag/drop from view to
Finder),
however it is also intended to allow the same rows to be dragged and
dropped between the two table views.
This is where the catch 22 seems to be. Since all drags of these table
view
rows are initiated as promised file drags (since when the drag is
intiated
it isn't known where it will be dropped, i.e. Finder or the other table
view),
both table views now have to support receiving promised file drops as
well as the normal file drops when they come from Finder. However a
a drop from one table view to the other requires different behaviour to
that for a drop from the Finder, and the problem I'm having in
particular
is to do with having the table receiving the drop being able to tell the
difference to implement this different behaviour.
Finder sets the dragging operation to NSDragOperationEvery when it
drops onto my app's table views, whereas I've changed the overloaded
draggingSourceOperationMaskForLocal: method to return
NSDragOperationPrivate when isLocal is true, to allow some means of
distinguishing between drops. The problem is that this information is
not available when namesOfPromisedFilesDroppedAtDestination:
is called on the table which is the source of the drag (which would be
the natural pace to initiate the operation associated with a drag and
drop,
as is already the case for promised drags to the Finder since this is
where
it gets told the path of the Finder folder where the drag was dropped).
The only information received here is a NSURL of a file path. I'd hoped
to be able to set this to nil in the overloaded performDragOperation:
method (called on the dragging destination when the promised file
drag is dropped) when it calls back on
namesOfPromisedFilesDroppedAtDestination:
but no that's not possible, in fact the NSURL can only point to a valid
file path, you can't even put "file:///ignoreThisItIsDummyData". Now
this
isn't very acceptable since if the path has to be a real one, it also
could
occur when a promised file drag is dropped on the Finder and so will
not be a reliable indicator of local/non-local drops.
Note that when a NSTableView receives a promised file drop, the
usual acceptDrop: delegate method isn't called (though validateDrop:
is), the only call once the drop has occurred is made to
namesOfPromisedFilesDroppedAtDestination:. Things would be a bit
different if acceptDrop: were called as it receives the
NSDragOperation and would be able to discriminate between the
NSDragOperationEvery and NSDragOperationPrivate values for
local and remote drags.
So I'm feeling a bit stuck and wondering if someone else has also hit
this and how it was resolved (assuming it was). Therefore any helpful
suggestions would be very gratefully received!
Regards,
Tim Hewett, Coolatoola.com
_______________________________________________
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.