Re: Help with pasteboard
Re: Help with pasteboard
- Subject: Re: Help with pasteboard
- From: Charles Srstka <email@hidden>
- Date: Thu, 18 Oct 2001 18:59:15 -0500
On Thursday, October 18, 2001, at 04:31 PM, Brian Webster wrote:
On Thursday, October 18, 2001, at 03:08 PM, Charles Srstka wrote:
On Thursday, October 18, 2001, at 02:03 PM, Brian Webster wrote:
OK, it appears that the Finder "prefers" to take the string rather
than the file if both are offered. It appears to really be an issue
with the Finder, not with your code specifically. When you drop your
data onto the Finder, does it correctly create a text clipping file?
Have you tried only offering the file contents type? Does it create
a plain text file then?
Hmm, I just tried doing that, and the drag operation was aborted each
time. When I dragged an item to the Finder, it would be flung right
back into my outline view. I used the following line to declare the
file type:
[pboard declareTypes:[NSArray
arrayWithObject:NSFileContentsPboardType] owner:self];
and the Finder would not accept a drag from my app. Even if I
immediately wrote the wrapper to the pasteboard right in the
writeItems: toPasteboard: method, the Finder would have none of it.
Apparently the Finder doesn't want to receive
NSFileContentsPboardType. Odd.
OK, here's what I've discovered after a little investigation. The
problem is that we're dragging between a Cocoa app and a Carbon app.
While a handful of drag flavors are translated by the unified dragging
mechanism, NSFileContentsPboardType (or flavorTypePromiseHFS in
Carbon-speak) does not appear to be one of them.
I ran a couple tests using a nice little app called Dragster, which
will accept any drag-and-drop input into a window and give you info on
what drag flavors are available, what the data is for each flavor,
etc. I tried dragging some items from various Cocoa apps to see what
showed up in the translation over to the Carbon drag manager.
Text dragged fine, as do existing files (NSFilenamesPboardType) dragged
from Project Builder or document proxy icons. However, file contents
did not show up at all when dragged over to the Dragster window. So,
it appears NSFileContentsPboardType does not get translated over to
flavorTypePromiseHFS. I would consider this to be a bug, or at the
very least a very important missing feature. I confirmed that it's not
a Finder-specific bug by being able to drag text from IE to the Finder,
and it created a plain text file just fine.
As for a workaround, I guess the only way to do it now is to instead
declare the NSFilenamesPboardType, write the data to a temporary file
(the NSTemporaryDirectory() function comes in handy here) and write its
path to the pasteboard. When the drop operation occurs, the Finder
should move/copy/link (depending on modifier keys) the file to the drop
destination. It's kinda ugly, but it should work.
--
Brian Webster
email@hidden
http://homepage.mac.com/bwebster
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Actually, this is kind of how my app currently works. However, this
approach has several problems of its own, which is why I was hoping to
be able to replace it with NSFileWrapper:
1. If the file doesn't already exist (i.e. if you only create it after
the user completes a drag and drop operation), the Finder won't accept a
drag of type NSFilenamesPboardType. The conversion only occurs if the
file already exists. Since my app sometimes deals with 200+ MB files,
I'd rather only create the files when I need to.
2. NSTemporaryDirectory() won't work (at least it didn't in 10.0.4),
because the Finder won't move the file, claiming it can't be found,
because /tmp is an invisible directory.
3. When you use NSFilenamesPboardType, the Finder assumes that it will
get the file immediately, because it's getting flavorTypeHFS instead of
flavorTypePromiseHFS. If it takes you too long to create the file, it
times out and the file doesn't get moved.
So, I'd really like another option. NSFileWrapper looks good, but what
I'd like even more is to know the path that I dragged the file to.
Unfortunately, it seems I can't use either. Great...