Question re: Limiting the number of dropped files

#1

I am using AppleScript ObjectiveC, so I am hesitant to use enhanced applets. I need to limit the number of dropped items. Is there a robust way of doing so?

#2

What do you mean by “limit the number”?

FWIW, you can also coalesce the open events received like this:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions
property filesToOpen : {}

on open fileList
	set my filesToOpen to my filesToOpen & fileList
	-- cancel any pending performSelector: requests
	current application's NSObject's cancelPreviousPerformRequestsWithTarget:me
	-- handle files after a short delay in case further events are received
	tell me to performSelector:"doOpen" withObject:(missing value) afterDelay:0.5
end open

on doOpen()
	copy my filesToOpen to fileList
	set my filesToOpen to {} -- reset for next time
	
	set aRes to length of fileList
	display dialog aRes as string
	
	repeat with i in fileList
		set j to POSIX path of i
		display dialog j
	end repeat
	
	tell me to quit
end doOpen

on quit
	continue quit
end quit
#3

Thanks for the suggestion, Shane. I saw your solution in another post and believe that I read that it also had some drawbacks. I looked at my code and was thinking I could likely live with limiting the number of dropped files to one. Is there a way of doing that, much like one does with choose statements?

#4

You can ignore all but the first, using on open{theFile}. But that doesn’t limit how often open is called.

#5

Thanks for the reply, Shane. I’ll give your code a try on my development version of MetaProxy (an app I’m developing). Does the delay on the “doOpen” have to be tweaked to the system or is the 0.5 value adequate for any system? I ask, because I’m looking at all my code to try to improve the speed. Half a second is not much, but I hope that’s all it needs to be to make things work reliably.

#6

Just tried the code as posted. Traced the flow with the debugger. It appears to repeatedly invoke the “on open file list” handler and never reaches the “on doOpen()” handler. It is as if the default handler is being re-triggered before it can invoke the second handler.

Any ideas?

#7

I finally located the post you made about this solution. I saw, in the text, that you said, “It needs to be saved stay-open.”. This doesn’t seem like something that one would do, if the script in question is not a daemon. Actually that is perhaps one answer… Create a drag and drop daemon that assembles the file list and then re-issues the call to the app with the dropped filenames all in one list. Not too elegant, but at least ones entire app wouldn’t be running all the time and it could be used by almost any other app.

Would this work or would we get caught in the same net as before?

#8

Why not? It just means the script takes responsibility for when to quit.

#9

Ok. I understand now. The only difference from a “normal” script is that I need to tell it when to quit. It doesn’t need to “stay open” all the time.

#10

That’s right. It really means don’t automatically quit at the end of the run handler.