Droplet bug

Hi CMYS,

The folder action worked:

on adding folder items to this_folder after receiving these_items
	set item1 to item 1 of these_items
	display dialog (item1 as string)
end adding folder items to

Usually, I try not to use folder actions, but this time it might be the other way around! :smiley:

Still, there might be a faster way?

Edited: the folder action doesn’t do it. You still can’t get a reference to the file that was added. Back to the drawing board. Unless there’s a way to get the reference to where the file was, in another way in the folder action.

Thanks,
kel

I found a solution with the folder action! We use the ‘removing folder items from’ right after. The file moves back to where you dragged it from and gives a reference to its new location. :smiley:

Edited: I forgot to add that we need to undo the first move in the Finder. After you undo the file moves back to where it originally was. Then you get a reference to its new location which was its original laceration before the drag. :slight_smile:

I still need to write the script and test it, but it might work.

Darn, it almost worked. There is still a delay before the second folder action runs. Here’s the two scripts:

on adding folder items to this_folder after receiving these_items
	set item1 to item 1 of these_items
	display dialog (item1 as string)
	tell application "Finder" to activate
	tell application "System Events"
		keystroke "z" using command down
	end tell
end adding folder items to
on removing folder items from this_folder after losing these_items
	set item1 to item 1 of these_items
	display dialog (item1 as string)
end removing folder items from

I can’t remember if there was a way to speed this up.

This seems to work much faster than anything so far:

set f to choose file
tell application "TextEdit"
	open f
	set d to document of front window
	set p to path of d
end tell

You choose the internet location file. Open in text edit. And get the document. Then get the path.

Edited: Finder must know where the file came from in order to undo.

Edited: think I’m going around in circles. Need a break.

Had an idea. We use the folder action, drop files on it, get the names of all the files that were dropped. So, we have the names of the files. Then do the undo. Then search all Finder’s windows for files with names in the list of file names. That might work!

Edited: it’s a pseudo droplet! :slight_smile:

A pseudo droplet, yes, but it works (or should work) as expected and above all by simply dragging files on an icon which is basically the droplet ease. :slight_smile:

Hi CMYS,

Started testing with the desktop window with an internet location file on the desktop. It seems to be working, but needs testing. Then expand to all open windows. Also, need to test consistency and time.

on adding folder items to this_folder after receiving these_items
	set item1 to item 1 of these_items
	tell application "System Events" to set item_name to name of item1
	display dialog item_name
	tell application "Finder" to activate
	tell application "System Events"
		keystroke "z" using command down
	end tell
	tell application "Finder"
		activate
		try
			set desk_window to window of desktop
			set item1_ref to (first item of desk_window whose name is item_name) as alias
			display dialog (item1_ref as string)
		on error err_msg
			display dialog err_msg
		end try
	end tell
	beep 1
end adding folder items to

I needed to do some review of desktop window.

Edited: sometimes the folder action doesn’t work if you drop a second file on the folder to soon. Maybe need to update Finder or relaunch System Events. Still testing.

Edited: found that the folder action doesn’t fire if you drop the same we bloc file too soon after the first. But, if you alternate different files, then it seems to be working.

gl,
kel

Got it working with multiple webloc files:

on adding folder items to this_folder after receiving these_items
	set file_names to {}
	repeat with this_item in these_items
		tell application "System Events" to set item_name to name of this_item
		set end of file_names to item_name
	end repeat
	tell application "Finder" to activate
	tell application "System Events"
		keystroke "z" using command down
	end tell
	tell application "Finder"
		activate
		set window_list to every window
		if not (exists window "Desktop") then
			set dtw to window of desktop
			set end of window_list to dtw
		end if
		set the_items to {}
		repeat with this_window in window_list
			set found_items to (every item of this_window whose name is in file_names) as alias list
			set the_items to the_items & found_items
		end repeat
	end tell
	-- test the_items
	set string_items to {}
	repeat with this_item in the_items
		set end of string_items to this_item as string
	end repeat
	activate
	choose from list string_items
	beep 1
end adding folder items to

It slows down with more open windows. Also, try not to drop the same files.

Edited: note that you cannot drag items of sublists when in list view.

Edited: I have a theory on why it doesn’t work when you immediately drop the same file on the folder. Finder seems to think that the file is still there. It has nothing to do with the name of the file though. Somehow, we need to force the Finder to now it’s not there. This happens in the opposite direction also. Rarely, when the file is moved (with undo) to the desktop, Finder thinks that something is there (i.e. under the hard disk) and moves the file to the next space. Tried updating the windows, but it didn’t work. Moving the file makes it work again with a longer delay.

Edited: getting real close. When I drop the same file and another file. The same file doesn’t show up in the choose from list dialog. I don’t think it’s erring. Need to check that out.

Edited: getting closer. The Finder thinks that some operation is not complete. Probably the undo?

Edited: I think System events is not reporting that the job is completed. I think this because, if I just manually move the file on the desktop and redrop it, then it works. Darn, let me try that again.

Edited: what I was thinking is that we might have to skip working with the desktop and just work with the desktop folder if it’s not already open.

gl,
kel

I’ve come to the conclusion again that fodder actions is a lame technology. It’s too slow! That’s why I never used it. It might be ok for simple stuff like displaying a dialog when an item is dropped and hopefully not too often.

But, I did have a new idea to solving this problem.

how about watchpaths? It’s using file system events, it should be a lot faster.

Hi DJ,

I was thinking of using something like a folder watcher instead of folder actions. I’ll look into “watchpaths” whatever that is. Think I’ve read about something like that in one of the developer docs.

Also, was thinking about the original idea of getting the Safari windows (or whatever is the default), get the urls, and finding the files in Finder’s open windows.

Edited: found it. It’s used in a launch agent.

Thanks a lot,
kel

Reading up on the various types of jobs, this looks like it might work also:

Yeah, after several hours off and on, finally got the launch agent to work. I think it was because I was using:

instead of:

which now works. Now I can call an AppleScript script. Probably, need to work on it tomorrow.

Btw, I think the QueueDirectories might work better, because the agent won’t run if the folder is not empty.

Thanks DJ! Forgot about Launch Agents.

Oops! Didn’t see your last posts earlier.
Just one thing: if you set item1 to item 1 of these_items you’ll never catch the other ones. Was it on purpose?

Hi CMYS,

Yes, I was just testing. :slight_smile: Sorry about not mentioning that.

As I was driving this morning, i remembered that an alias (path) reference follows the items where they are moved. So, it is not actually needed to check all Finder windows. So basically, all that needs to be done is get an alias list and undo the drag and drop. We then have a list of items wherever they came from! I must be getting old. :slight_smile:

Just started working on the whole thing.

Later,
kel

I see why now. The directory is never empty because of invisible files. So we need to use WatchPaths .

Hi Dj,

If you’re not too busy, I’ve noticed that when the files are removed from the drop folder, then the launch agent fires again. Should I unload the agent before removing the added items with:

then, remove the items from the drop folder. Or, is there a better way to not make it fire again? I couldn’t find anything in the man page for launched.plist for not having it fire again.

Btw, the speed of execution is great!

Thanks,
kel

Darn, one missing colon in the folder path caused another 2 hours of debugging! Think I’ve got it now!

Hi,

Think I’ve found the secret. You need to unload and load at the end of the AppleScript. Otherwise, your program will act funny. :slight_smile:

This is a great puzzle man!

Darn, no you need to reload it somewhere else. This is so frustrating, but I love it!