Drag-n-Drop *and* Direct Access...possible?

Scripting Forums AppleScript | Mac OS X
#1

[I swear I’ve seen this answered in this forum, but I’ll be darned if I can find it now that I’m actively looking for it…]

I have an AppleScript to convert files to PDF that I want to get it’s inputs in two different ways:

–Drag-n-Drop of one or multiple files
–A file alias provided to the script directly (via feedback Prefab’s UI Actions…I think, still reading the tutorials)

The “on open” handler will get the list of file(s) from a drag-n-drop, but how do I fire-off the script if the input isn’t from a drag-n-drop?

Maybe a simpler question:

How would I set-up an droplet to function as a droplet (receiving alias list via drag-n-drop) and via, say, a dialog box if you simply double-clicked the same script to launch it as an application?

Thanks in advance,

–Kevin

#2

You include an ‘on run’ handler which acts when the script is double-clicked or when it is invoked from another.

‘on run’ handlers are usually implicit - i.e. when you run the script everything that is not a handler itself runs. To do what you want to do, you need to make it explicit - actually put the stuff you want to happen on a start that is not a drop inside ‘on run’, ‘end run’. The ‘on open’ runs for a drop, the ‘on run’ for any other start. If it makes sense, the rest of the script can be a handler started from either of those, but more normally, the ‘on run’ portion has to get materials to work with, while the ‘on open’ is “handed” it.

#3

as an example…

on run
	myMsg()
end run

on myMsg()
	display dialog "Ain't it kewl."
end myMsg

on open
	myMsg()
end open

EDITED to add: except for your script, it sounds like you need a ‘choose’ statement for when it’s double clicked. still should be fairly simple.

#4

Okay so you’re saying I need an “on run” and “on open” and each of those pass to a third script which is the “real” executable, using “on open” and “on run” simply as methods for getting the input?

That and also make sure there is no executable code outside the handlers (nothing that could be run implicitly), unless that is required.

(That seems to be what waltr’s example implies.)

If so, that is nice and tidy. :smiley:

#5

You’ll soon know about stuff outside any handlers - the script won’t compile.

You don’t have to pass the results of the ‘on run’ or ‘on open’ handlers to a separate script, just to a handler that does the work after either of the other two establish what the input is.

#6

I typically use something like this:

on run
	choose file with prompt "Whatever:" with multiple selections allowed without invisibles
	open result
end run

on open theseItems
	-- Add some stuff here if you need to
	
	repeat with thisItem in theseItems
		-- handle thisItem
	end repeat
end open
#7

cringe

It was the end of the day, that is exactly what I meant…too bad it isn’t what I typed. DOH!

–Kevin