i’m trying to write a droplet that will operate in various ways on files dragged to it.
for the most part it work very well… except for one thing:
when an alias is dragged to the droplet, it is automatically resolves, and the droplet processes the original.
i’ve looked around and found only one post about this problem, and it is from more than 2 years ago. the solution suggested there by Fredo d;o), is to use selected files instead of dragged ones. for example:
instead of:
on open thefiles
--do something to thefiles
end open
use :
on open
tell application "Finder" to set thefiles to the selection
--do something to thefiles
end open
however, this isn’t always an acceptable solution, since it will always process selected files on the frontmost finder window even if files where dragged from another window without making it active. (pretty common).
for instance:
your droplet is on the desktop or in the dock, you have files a and b selected in the front window, and you drag file c from the desktop to the droplet. → files a and b are processed. not what you’d normally want.
did anybody find another solution to this behavior?
or maybe there is some kind of fix? (i’m assuming that this is a bug and not a feature since none of the other ways to refer to files in AS, automatically resolve aliases.)
No, it’s not a bug. It’s what alias files are for. You can drag them to droplets, drag stuff to them, or double-click them and it’s as if you’ve done exactly the same things with the originals. The Finder selection hack is useful if you want to do something unusual on your own machine, but, as you’ve observed, it’s not so reliable that you can afford to be cavalier with it. If you need to do something that involves dragging and treats alias files as alias files, you might find a folder action more suitable. (Obviously, though, this means that the files will end up somewhere else.) Or you could process the folder containing the aliases…
thanks for your reply Nigel.
i understand what aliases are for.
i still find this feature odd, since aliases are not being consistently treated this way, especially by the finder where many actions (moving, copying, renaming, deleting etc.) on aliases do not affect the originals, and since it is very easy to resolve an alias programatically within an applescript droplet (using original item of) you could have the two options.
anyway, judging by the lack of discussion on the matter, most people seem to be happy with the way things work currently so it’s probably not going to change.
regardless, i’ve found a way to make the finder selection hack more reliable, by adding a subroutine which makes sure that the selected files and the files dragged to the droplet are the same ones, before performing any action on them.
i’m not an experienced scripter, so please bare with me…
on open opened_items
tell application "Finder" to set selected_items to the selection
set the_same to my check_selection(opened_items, selected_items)
if the_same then
-- do somthing to selected_items
end if
end open
end
on check_selection(opened_items, selected_items)
tell application "Finder"
set alloriginals to {}
-- make a list of finder selection with resovled aliases
repeat with sel_item in selected_items
if (kind of sel_item) is "alias" then
set sel_item to original item of sel_item
end if
set alloriginals to alloriginals & (sel_item as text)
end repeat
set alloriginals to alloriginals as text
set opened_items to opened_items as text
--check if the new list containes the same items as the opened items
set the_same to true
repeat with x in opened_items
if (alloriginals contains x) is false then
set the_same to false
exit repeat
end if
end repeat
repeat with x in alloriginals
if (opened_items contains x) is false then
set the_same to false
end if
end repeat
return the_same
end tell
end check_selection
now, if there was a way to repeat the subroutine with finder selection in windows other than the frontmost one, i could find a complete solution to my problem…
by i can’t seem to find it, there use to be a way in classic back in the days, something along the lines of:
every item of the desktop whose (selected is true)
that doesn’t work anymore, is there an alternative?
As a scripter, I agree it would sometimes be more convenient if droplets could receive alias files that were dragged to them rather than the original items. But the current system is consistent. The mechanism for dragging files and folders to an AppleScript droplet is the same as for dragging them to any other application. It happens in the Finder and it’s the Finder’s responsibility to see that the right application is sent the ‘open’ command and that this is accompanied by the appropriate aliases. (‘Aliases’ as opposed to ‘alias files’ here.) The official Mac OS behaviour is that if an alias file is dragged to an application icon, the application will ‘open’ the item to which the alias file refers. Having the Finder sort out the original item means that application developers don’t need to take special steps to implement the standard behaviour. It also means that the interpretation of alias files is guaranteed to be standard and that end users won’t be confused by different applications reacting to alias files in different ways.
Scripting for your own personal use, of course, there’s no need to be quite so pedantic. If you have the special knowledge that a droplet you’ve written handles alias files per se, then that’s your own business. I’ve been trying to think of a way to make the selection hack more foolproof, but with no luck so far. You may need to use your droplet with the special knowledge that alias files have to be selected and dropped in a certain way.
i’m actually convinced by now that the way alias files are interpreted by AS droplets is consistent with the OS standards, and it does make sense to me now.
however, one may occasionally find it useful to have a droplet treat an alias file as is, the main reason i can think of for now, is if the droplet is meant to extend or automate the finder’s functionality, and needs to imitate the way drag & drop operation of aliases to anything but applications are carried out by the finder.
again, not many people seem to be looking for it…
but i did come up with a reliable (or so it seems to be) way to achieve that, and it is indeed by making the finder selection hack more foolproof.
instead of posting here the entire code which is kinda longish, and possibly awkwardly written, i’ll describe how it works step by step:
get a list of items opened by the droplet (drag&drop)
get a list of items in finder’s selection in the active window
compare the two lists using the code in the post above, to determine if the drag&drop occurred in the active (front) window. (it will be in most cases under typical use in the finder)
if it is:
4. process items in finder’s selection → exit
it it’s not:
5. get a list of all non-active finder windows (including the desktop), which contain any of the opened items. (except for the fairly rare case of dragging an alias in a non- active window and having the original in another none-active window, this list will contain only 1 item).
6. repeat in every window from the list above (typically only one), make it active, get the selection and compare it to the list of opened items.
when it matches:
7. process item's in finder's selection (in the currently active window).
exit.
i have used this method in many different situations, and so far it works perfectly.
if anyone is interested i’ll post the code.
Hi, noiroi. I’m glad you’ve got something that works for you. kel’s suggestion looks good too. I downloaded BigCat last year to try something out for someone, but I’m afraid I haven’t looked at it much since then. I must do so.
I’d be interested to see how you determine which window’s “active” when you include the desktop. That’s what defeated me. You can use the Finder’s ‘insertion location’ and the windows’ indices up to a point. But how do you make the desktop itself “active”? Opening a Finder window on it won’t do because the selection on the desktop won’t be reflected in the window.
I’m not surprised! Thanks for posting that. It’s a good one to know.
Just click on “Quote” instead of “Post reply” at the bottom of the message to which you want to reply. You’ll see the BBCode quote attribution format in the message panel of the reply window that comes up. There used to be a BBCode Guide somewhere on this site. I don’t know if it’s still around.
Later edit: No it’s not. But the very same document is at this link.
ok, the solution i’ve posted above, is obviously not perfect, as it turns out. it handles properly situations in which items are dragged form an inactive window, but not when a single item is dragged without being selected while another item in the same window, is. i can’t believe how difficult it is to get around this thing! i’m gonna keep trying…
but i would really like to take a moment to explain why i think this is so important:
trying to use AS droplet for file and folder manipulation that complete or enhance the finder’s functionality, may lead to problematic or even dangerous results.
for example:
you have a folder in which you throw miscellaneous files related to recent work, (possibly your desktop), including some aliases of frequently used project specific file and folders. project is over, and you don’t need all this mess in your folder anymore, but you don’t feel like sorting everything out just yet, so you select all the recent files, copy them to a folder on an external volume, and then, confident that you’ve just made a backup proceed to drag those same items to a droplet that deletes file, securely, even if they’re locked…etc (pretty popular feature). it will delete original files on your hard-disk while you backed-up only their aliases. obviously, such a droplet must not be used. a backwards scenario. i.e. - using a droplet to make a backup and the finder to delete, will also yield undesired, even if not as devastating results. and examples are numerous…
with a lack of a solution or a solid work-around , i feel that we have to acknowledge AS droplets as unsuitable for file and folder manipulation from within the finder. i am surprised that not more people are having issues with this…
am i missing something?
When posting a message, it should normally be possible to access the on-site guide by clicking on the text marked BBCode (just below the message editing pane), Nigel.
on open theDropList
tell application "Finder"
open folder of item 1 of theDropList
activate
set theSelectList to get selection
-- the rest of the script
end tell
end open
i can’t believe how difficult it is to get around this thing! i’m gonna keep trying…
