[barney ntd]

How do I implement drag & drop to the finder, if I need to delay writing the file until the drag succeeds? I have tried the new instructions on apple's web site, and every variation of them I can think of, but I can't get the finder to accept a drag except of an existing file. The web pages say you can delay writing the data to the drag pasteboard, but if you do, the finder refuses to accept it. Am I doing something wrong, or is it just impossible?

Barney.

[seb2]

what new instructions on the apple site?

as far as i know, flavorTypePromiseHFS doesn't work from cocoa now but is promised for 10.2. just promising files to the finder without putting paths to already existing files onto the pasteboard doesn't work (the "lazy" way you tried), the finder wants the info right at that moment.

there are a few ugly workarounds...

[edit: made it clearer]

[ 03-12-2002: Message edited by: seb2 ]

[barney ntd]

Thanks. I'll wait for 10.2 then.

The new instructions I was refering to are the bits of the developer documentation which they have recently updated, but not yet put into a free dev tools update. Just basic instructions for using drag and drop, which encouraged me to try it in the first place.

Barney.

[jmonteiro]

Originally posted by seb2:
<STRONG>what new instructions on the apple site?

as far as i know, flavorTypePromiseHFS doesn't work from cocoa now but is promised for 10.2. just promising files to the finder without putting paths to already existing files onto the pasteboard doesn't work (the "lazy" way you tried), the finder wants the info right at that moment.

there are a few ugly workarounds...

[edit: made it clearer]

[ 03-12-2002: Message edited by: seb2 ]</STRONG>

Where can I find some information on the "ugly workarounds"?

[seb2]

Originally posted by jmonteiro:
<STRONG>

Where can I find some information on the "ugly workarounds"?</STRONG>

just be creative. basically, you do everything yourself.

hand the finder an empty temporary file, find out where it went, delete it and put the real file there.

a very simple idea might be to create a file with some name in /tmp, create a hard link to it (with the "real name", also in /tmp) and hand the finder the hard link. once the drag is over, fill your first file with the final contents and delete it afterwards.

of course, this won't work over different volumes, hard links just don't. also, you could get in trouble if a file by the required name already existed in /tmp.

on the other hand, it's a lot easier than solution number one.

i'm facing a similar situation at the moment and decided to go for a menuitem that lets you choose the destination for the file via an open browser (yup, open -- doesn't let you enter a file name and you can set it to only allow the selection of directories)

until apple fixes this, i just decided it wasn't worth all the trouble.

[CharlesS]

Originally posted by jmonteiro:
<STRONG>

Where can I find some information on the "ugly workarounds"?</STRONG>

Sebastian is probably referring to the one I thought up when we were discussing drag and drop in our programs. Originally I tried a billion things, trying to get d&d to work in a program I wrote, Pacifist. There is just no way to drag and drop a non-existing file to the Finder right now, but I've been told by someone at Apple that support for sending flavorTypePromiseHFS, which is what you need to "promise" to the Finder that a file that doesn't exist now will exist later, from Cocoa is planned for "the next release," which I assume is 10.2.

Of course, this person may have just told me that to shut me up, as I'd kind of been spamming the cocoa-feedback e-mail address about this, sending the request again every month or two...

Anyway, here's the workaround I thought up. Keep in mind that this is purely hypothetical - I have not actually implemented or tested this at all; it's only a thought at the moment. If the Apple tech's promise turns out to be false and 10.2 comes out without support for flavorTypePromiseHFS, I may resort to this workaround. Until then, it is merely speculation. Even if it works, it is rather ugly, as Sebastian noted.

Anyway, here's what I thought of doing - at the time the drag is initiated, create a zero-length file in a temporary directory somewhere. Give it a distinctive name, preferably something with a bunch of numbers in it that encode the current date and time, process ID, or whatever, so that the filename is guaranteed to be unique. Get an alias record of that file. Give that file to the Finder and let it drag and drop it to where it needs to go. Then, resolve the alias record. If the user dragged it to somewhere on the same disk, the alias should resolve - store the path of the folder the file is now in, delete the file, and put your new files there when they're ready. If the user drags to a different disk, then the alias won't resolve, and this is where things get ugly. You have to search all drives for the file with your (hopefully unique) filename. There's a function called MatchAlias() that is supposed to do this automatically for you, but since I have heard that it is unreliable, you will probably have to just get an NSDirectoryEnumerator and scan everything on the drives until you find the file. Make sure the file is zero-length before storing its path and deleting it, because otherwise you might delete the wrong file! Oh, and if you need to put something in a folder that's owned by root, forget it, because the Finder won't move the zero-length file there.

See why I'm waiting on 10.2?

[CharlesS]

Rats, Sebastian, you beat me to it.

Ah well, my description was more complete anyway.

One thing I would like to add is not to mess with hard links - they're dangerous. Use alias records instead - you have to use a little Carbon to do it, but it's not that bad. Really. I promise.

[seb2]

Originally posted by CharlesS:
<STRONG>Rats, Sebastian, you beat me to it.

Ah well, my description was more complete anyway.

...</STRONG>

yep, yours was more complete.

let me just add that scanning entire drives with directoryenumerators can take a loooong time... i happen to have played around with them a bit.

[CharlesS]

Originally posted by seb2:
<STRONG>let me just add that scanning entire drives with directoryenumerators can take a loooong time... i happen to have played around with them a bit. </STRONG>

Really? Damn, I guess that means you'd have to use either Carbon or the BSD stuff, then. Or MatchAlias(), if it works...