List folder sub-routine sometimes returns strange list

Wierd and wild. :smiley:

Applications act like they’re in the dock or launchpad.

It is isn’t it? My guess, is that the try end try block, “Covers” or “Smoothes” over “Something”, and only God knows where that “Something” resides, somewhere in between Finder and the applet/droplet I guess, but not sure about anything here.

It works, so why should I care as long as it solves the problem. :smiley:

What do you mean by that? I can only guess, and I am afraid the guess would be very inaccurate… :slight_smile:

You were writing about running apps with one click. Anyway, it reminded me of running compiled scripts from a script runner and I wondered if it would work in mountain lion.

I created two scripts the first is an application ScriptRunner:

on open (params)
	display dialog (params as string)
	return
end open

The second is a compiled script:

display dialog "hello"

After creating the two scripts, get info on the compiled script and choose open with the ScriptRunner. Now when you double click on the compiled script, you can make it run. It’s working great with this system so far.

Edited: I saved the script app as stay open, but don’t know if it’s necessary.

Sorry for straying a bit.

Hello.

What’s probably happening, is that when everything is executed within the try - end try block, then any state that otherwise would have been saved, and thereafter would be wrong when something has changed, are unaltered, and therefore the applet/droplet works flawlessly at all times, (at least when those matters are concerned.)

I am pondering having extra folders as menu items, but I fear it will become too much.

Currently reading Guy Kawasaki’s (the Mac Evangelist, who started up the database company 4D ) Database 101, for my entertainment, you should be able to get hold of a free copy on the net, but I’ll email you one if you are interested.

Thanks McUsr, but I have too moch to read already. :slight_smile: Maybe one of these days I’ll get around to reading Guy’s books. It’s probably way over my head anyway right now.

About the script runner, this runs the compiled script:

on open (params)
	set script_ref to item 1 of params
	run script script_ref
	return
end open

Just finishing up if anybody is interested.

gl,
kel

I thought that text entered in the applescript tags were checked by a compiler.

You have obviously never read any of Guy Kawasaki’s books :smiley: They are easer to read than watching a video!

I tend to use AppleScript runner when I run scripts, because then I know who runs it, (from other apps with possible other script runners), and that I have a reasonably hope that properties gets to be saved back into the script.

I don’t know if there are really any differences among the two approaches, except for my way of doing it being slower, when you know that it is the Applescript runner that runs the script in the end anyway.

Edit

An applet that uses AppleScript Runner is of course also much more robust to faulty scripts, than running them in the same process with run script.