Is it possible to run an applescript within a script based on text entered by the user, For example say I have a script that runs in the background as a handler, I open the script and it would have a dialog box asking for a command by entering text. I have a script written that will launch iTunes, when the dialog box appears I want to be able to type in “launch iTunes” and run the iTunes script, how would I do this?
Any help would be greatly appreciated,
googleman76
To run scripts in the background I refer to this.
set cmd to text returned of (display dialog "What do you want to do?" default answer "")
if cmd = "Launch iTunes" then run iTunesLauncher
script iTunesLauncher --this can be the contents of an AS file loaded with 'load script'
launch application "iTunes"
end script
thanks, that helps a lot, what do you mean when you say?
script iTunesLauncher --this can be the contents of an AS file loaded with ‘load script’
googleman76
The line:
launch application "iTunes"
could be stored into an applescript file and loaded into a variable named ‘iTunesLauncher’. For example when the you store this that line in a file on your desktop and name it ‘iTunesLauncher.scpt’ you can load the script with:
set iTunesLauncher to load script file ((path to desktop as string) & "iTunesLauncher.scpt")
thanks, that makes sense
googleman76
I don’t know what you mean by a script that runs in the background. I do however
know how to run an app in the background and such AppleScript daemons can be
very useful and flexible. I append a working script for such an applet. Follow the
instructions at the top.
Such applets are never visible and never come to the front and it’s important to
tell them to quit (tell app “ASDaemon” to quit) before you make changes to them
in AppleScript Editor.
Once you have saved it and launched it, you can get it to do anything you want:
tell application “ASDaemon” to run_itunes()
tell application “ASDaemon” to tell_me_where_you_are()
tell application “ASDaemon” to tell_me_the_time()
You can also pass arguments (parameters) to handlers in the app or ask it about
its properties. Tasks can also be performed at intervals within an idle handler.
JD
(*
ASDaemon.app”Invisible Background Application
1. Save this as "Application" , checking the box "Stay open after run handler"
2. Go to the app in the Finder, right-click and select "Show Package Contents"
3. Expand Contents and drag "Info.plist" to a text editor
4. Insert these two lines after <dict> near the top of the file, and save
<key>LSUIElement</key>
<string>true</string>
*)
property _Path : missing value
set _Path to POSIX path of (path to me)
on tell_me_the_time()
set _time to time string of (current date)
display dialog return & "The time is" & return & ¬
_time buttons "Thanks!" default button 1 with icon 1
end tell_me_the_time
on tell_me_where_you_are()
set _dd to display dialog return & "I'm here:" & return & ¬
_Path buttons {"Quit", "Thanks!"} default button 2 with icon 1
if the button returned in _dd is "Quit" then quit
end tell_me_where_you_are
on run_itunes()
tell application "iTunes"
launch
activate
end tell
end run_itunes
on quit
continue quit
end quit
Model: Mac Mini Intel
AppleScript: 2.2.3
Browser: Firefox 16.0
Operating System: Mac OS X (10.8)
Hi John.
I’ve often seen an apparently pointless ‘quit’ handler included in people’s stay-open code. Is there a rationale behind it?
Maybe you can script it to quit then?
Wouldn’t you either not save it as a stay open application or quit it like any other application?
A ‘quit’ event intercept which only says “OK. Carry on” may just as well not be there.
Quite so, but I was giving an example that contained some pretty pointless handlers as well, so perhaps it would have been more useful to post an empty script and save myself a bit of bother.
The point is that you are able to intercept the quit event and do other things on receiving the quit event. You then need to ‘continue quit’. That is may be no news to you but it may be news to other readers.
on quit
display dialog "Goodbye" buttons " " giving up after 1
continue quit
end quit
Practically “every other application” when told to quit, needs to tidy up, turn off the gas, switch out the lights etc. before responding. Otherwise there can be a hell of a mess to come back to. Some apps, such as BBEdit, make careful preparations while running so that a forced quit is not a disaster. Others don’t.
JD
I have used to have it for convenience purposes during debugging, because it as waay to hard to go to the Activity monitor and kill it from there!
So, I think it is an ok event handler to have during development. 
Though unnecessary for plain quitting!
If you specify the on quit handler, then you have to continue quit.
At least I have, on my machine. I think this is due to the inheritance chain. The application has those handlers wired into itself whether you use them or not. (All cocoa applications have them). So we follow an inheritance chain here. Our quit handler has “overridden” the parent’s so we have to make the parent do the rest of the quitting.
The continue keyword, lets you carry on with the task of the parent, which is one of the things that makes AppleScript able to handle polymorphism. So that you can add behaviour in a child object, then call the parent’s version, to do the general stuff, if the parent’s handler uses the keyword me, the child would be me when the parents handler are invoked.
If I don’t specify the quit handler, then the applications quit handler are called directly, and not the scripts.
So, if you need a quithandler to do specialized quitting, then you have to continue quitting. if there are no specialized things to do, simply don’t include it. It is there, for free.
Edit
This usage of continue for the quit handler, isn’t uniform behaviour for the rest of the handlers, as you don’t have to continue run, open, print, open location etc.
I think the fact that this particular handler is implemented this way, has to do with saving the state of an application when it quits, maybe writing a window position back to a nib file etc.
Edit++
There aren’t many nib files in an applet, so the most probable reason it is implented this way, is to ensure that quitting works from an applets menu.
Ah. You are the same John Delacour who used to contribute to AppleScript-Users and MACSCRPT a decade or so ago. :lol: Welcome here!
My point was that I’ve seen many examples of stay-open code posted over the years with a ‘quit’ handler which only continues the quit and I was wondering if it was one of those self-pertuating oddities like ‘characters x thru y as string’, ‘count of .’, and telling the FInder to do everything, or whether the authors really did have good, conscious reasons for including it. I immediately suspected the latter in your case, of course. 
Not really. The whole point of sudden termination and automatic termination, which Apple recommends these days, is that the system can kill an app at any time. Leaving house-keeping until the last minute is generally frowned upon.
You failed to include in your quote the bit where I made precisely the same point. Are you at a loose end or something?!
JD
Except you didn’t. Force quitting in apps that don’t do some sort of auto-saving can mean lost data, but the idea of “a hell of a mess to come back to” is colourful nonsense. Preference saving is handled automatically, memory is reclaimed, open files are closed, and so on.