2 things.
- I have a helper script with a few standard things I can call in any of my ordinary applescripts. Here’s the helper (it’s still pretty small):
on activate_window(window_title)
tell application id "sevs"
try
tell process window_title to set frontmost to true
on error number -10006
display dialog "The window '" & window_title & "' doesn't seem to exist. So we can't bring it to the front...!"
return
end try
end tell
end activate_window
-- `menu_click`, by Jacob Rus, September 2006
--
-- Accepts a list of form: `{"Finder", "View", "Arrange By", "Date"}`
-- Execute the specified menu item. In this case, assuming the Finder
-- is the active application, arranging the frontmost folder by date.
on menu_click(mList)
local appName, topMenu, r
-- Validate our input
if mList's length < 3 then error "Menu list is not long enough"
-- Set these variables for clarity and brevity later on
set {appName, topMenu} to (items 1 through 2 of mList)
set r to (items 3 through (mList's length) of mList)
-- This overly-long line calls the menu_recurse function with
-- two arguments: r, and a reference to the top-level menu
tell application "System Events" to my menu_click_recurse(r, ((process appName)'s ¬
(menu bar 1)'s (menu bar item topMenu)'s (menu topMenu)))
end menu_click
on menu_click_recurse(mList, parentObject)
local f, r
-- `f` = first item, `r` = rest of items
set f to item 1 of mList
if mList's length > 1 then set r to (items 2 through (mList's length) of mList)
-- either actually click the menu item, or recurse again
tell application "System Events"
if mList's length is 1 then
click parentObject's menu item f
else
my menu_click_recurse(r, (parentObject's (menu item f)'s (menu f)))
end if
end tell
end menu_click_recurse
on win_wait_active(theObjectID, appName)
tell application "System Events"
set anInteger to "0" as integer
repeat until exists window theObjectID of process appName
delay 0.2
set anInteger to anInteger + 1
if anInteger is greater than 10 then
display dialog "Times UP"
return
end if
end repeat
end tell
end win_wait_active
This saves a lot of code and makes things reusable. The only downside is that the helper file has to be in the same directory, which I have no problem with. But is there any major performance issues or any other unforseen issues that might arise by structuring my scripts this way? (with a helper script for common functions)
- One issue that I have to address… If something encounters an error in the helper file, let’s say the win_wait_active times out, I need it to stop. The return will stop the execution of that function but in the file that actually is doing the primary automation, the file that called upon the helper, it will simply continue executing. I want that one to stop as well.
I tried this from someone else’s post, but I can’t use it because the compiler wants to know where AppleScript Runner is. It doesn’t exist until it’s executing… right? So how would I be able to compile it?
Any advice to this solution?
on kill_script()
tell application "AppleScript Runner" to quit
end kill_script