Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Excellent! | 25 comments | Create New Account
Click here to return to the 'Excellent!' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Authored by: jakecigar on Sep 28, '06 07:38:31PM

if he moved the activate into the helper, it wouldn't be 100% generic. it would just be a itunes script.

[ Reply to This | # ]
Not quite what I asked
Authored by: jecwobble on Sep 29, '06 08:24:03AM
He passes the app name ("iTunes" in his example) to the helper function. What I was asking is why not use that function argument to tell the appropriate app to activate. Like the "WHY NOT..." part below:

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)

    tell app appName to activate

    -- This overly-long line calls the menu_recurse function with
    -- two arguments: r, and a reference to the top-level menu
    tell app "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

[ Reply to This | # ]
Not quite what I asked
Authored by: jacobolus on Sep 29, '06 06:47:25PM

Yeah, that makes quite a bit of sense. I guess I never thought about it. One thing worth pondering is that I think some applications may do something if you activate them when they're already frontmost (applications can handle the activate message however they want AFAIK). So if we grab multiple menu items in a row, the app will end up being activated several times. Still, this probably a non-issue, so go ahead and add that line.

[ Reply to This | # ]