Hi All,
I have a script that automatically opens its target application if it isn’t open when the script launches.
Is it possible to do the reverse? If the application is opened and the script is not, can the opening of the application trigger the script to launch? Can this be done with “System Events” or some other tricks?
Thanks for any tip.
archseed
You’d need something that detects the launch of that specific application.
That could be a Quickeys-macro or an stay-open script with an idle handler in it.
But such a script has to be active all the time,
which raises the question why not make the original script a stay-open script that has an idle handler:
global AllApps
on idle
set theApp to "TheAppYouWantToDetect"
tell application system events to set AllApps to name of the application processes
If AllApps contains theApp then myAction()
return 30 -- or any other value in secs that this handler should be repeated
end idle
on myAction
– everything you want the script to do
end myAction
Thanks Eelco.
I was actually not thinking of another app like Quickeys but keep the action in AppleScript and the target app.
Your suggestion of keeping the action on idler came to mind. The script that I have already working is actually a stay-open app (with idler) that detects the presence or absence of the target app. That is working fine. My current interest is to implement the reverse, i.e., if the target app is launched independently, with the controlling script inactive, whether it is possible for the app to conversely trigger the script to start launching so that it can do its programmed task on the target app.
I guess it may not be possible to get to the innards of the target app and insert a code to do this. It used to be possible long ago with DOS/PRODOS/CPM programs to be able to get in and change the codes…to customize. Nowadays, things are just too complicated.
archseed
Interesting point.
I am not very knowledgeable about the innards of applications and bundles, but it should be possible to hook some (alias-like) reference into an application (which in OSX is actually a folder) that launches something else along with the app.
Some developers will obviously know.
If you find something, publish it here…!
OK. I will keep researching that trick and post anything interesting that I come across.
Meanwhile, my only solution which, in a way, parallels your suggestion, is to create a third, stay-open script that monitors the status of the target app and the supposedly “companion” script so that corrective action could be taken if one or both of principal apps quit, either by user’s choice or thru runtime error.
Thus far, it is working but I am not quite satisfied that a separate controlling script had to be created just for this purpose. How I wish I could just make the script and the target app to be mutually dependent. The question is how?
Anybody out there with a brilliant suggestion?
archseed
While reading this thread I got a funny idea. Why not just make the target application a resource of the script itself? You could give your script application bundle the same name and icon as the target application so that the user would never notice the difference. My simple experiment here worked great. This should probably be stress tested.
(path to resource "Chess.app")
tell application "Finder"
open result
open (path to desktop folder as string) & "Hi.app" -- a test script to run
end tell
- save that on the desktop as a script application bundle named “Chess”
- control-click on its desktop icon, click ‘Show Package Contents’
- drag the real Chess.app from applications and drop it in Contents > Resources
- select Chess.app, hit command-i, click the icon at the top, hit command=c
- close the bundle, select the script application bundle icon, hit command=i, click the icon at top, command-v
Update: I knew this would cause some weirdness. I’m impressed, however, by how well the system handles it.
good - If you open a document owned by the application, the real application actually opens the file
bad - this circumvents the whole purpose of the script bundle, and Hi.app never runs
good - Apple Events get sent to the real application instead of the script application
bad - Clicking the script application in the dock causes the real application to create a duplicate icon, pretty much giving away the secret, and possibly leading to user hilarity.
FWIW I’m aware of at least one app out there that monitors the system for application launch/activation, it’s made by prefab.
Hi silvermeteors,
Thanks for thinking about it and putting out a possible solution.
Mindful of the “bad”, I will try your hack and see if there are ways to work out the kinks. I am pretty sure other readers of this post and this thread will see your idea and tinker with it, much like I will do myself. I think it’ll be a pretty useful trick if a clean solution could be eventually worked out…a mutually dependent script and target app.
archseed
Indeed a funny idea - it even works with an alias to the target app.
Another link to the target app could be in the name of the script app itself.
Create an applet with the following code:
tell application "Finder"
set Path2Me to (path to me) as string -- get FilePath of this app
set AppleScript's text item delimiters to ":"
set MyAppName to text item -1 of Path2Me -- get name only of this app
set AppleScript's text item delimiters to ""
if ".app" is in MyAppName then set MyAppName to text from character 1 of MyAppName to -5 of MyAppName
if "*" is in MyAppName then set MyAppName to text from character 1 of MyAppName to -2 of MyAppName
open (path to desktop folder as string) & "Hi.app" -- a test script to run
end tell
Give it an existing application name and add a “" (e.g. "Microsoft Word”)
It will launch the original MS Word and also do its contained scripting
(compact, self-contained and less confusing).
Hi,
I have tried your suggestions and so far, your end product is working alright. Now, I am just putting it to further stress-test to make sure it does not do anything hilarious:D.
Will let this thread know what’s the happy ending.
Thanks.
archseed