Skip navigation

Applescript Input into Automator input...

1959 Views 38 Replies Latest reply: Apr 3, 2013 6:38 AM by mtimmons RSS
1 2 3 Previous Next
mtimmons Calculating status...
Currently Being Moderated
Jan 26, 2013 1:01 PM

I have a nice little applescript (on run.. inputObects) that presents a list of actions to perform on the files dropped. One of these actions is a simple copy using cp in the shell. Everything works great, execept, I need a way to cancel the script. yes, I could do a file > Quit on the scrip App. But, for my users, that is not convenient. I like how automater puts a 'cog' in th menubar that you can 'cancel' a script with. However, my applescript is too complicated for automator as the main app because of resources and other things I am doing.


I tried creating a 'dummy' automater script that delays indefinently but has an 'on quit' hander quitting the main applscript app. However, when choosing to 'cancel the workflow' from the cog, it does not run the worflows 'on quit' handler.. and thus does not solve my problem.


That said, I desire to change to bavior for the applscript to open an automater app that does the actions instead of nesting them in my main script....Unless there is a better way to implement a "cancel" of Applscript while it is doing 'stuff'.


So, does anyone know how to send the same input from the dropped-on file into the automator's inputs? and then get the return?


here is a code scketch.. very simplified. (applescript read-only app):


on open of inputObjects

          set workerPath to quoted form of POSIX path of (path to resource "" in directory "Scripts")

  do shell script "open " & workerPath & inputObjects


  -- now, get the output form the automator script..

  display dialog allNames


end open



Automator, applescript (


on open of inputObjects

          repeat with i in inputObjects

                    set fileCopies to fileCopies & inputObjects

                    set fposix to the quoted form of the POSIX path of i

                    do shell script "cp -f " & fposix & " ~/Desktop/"

  --- GET ALL THE FILENAME(S) of files dropped

                    set oD to AppleScript's text item delimiters

                    set AppleScript's text item delimiters to {"/"}

                    set fileName to (last text item of fposix)

                    set AppleScript's text item delimiters to oD

                    set AppleScript's text item delimiters to "."

                    if number of text items of fileName > 1 then

                              set finalName to text items 1 thru -2 of fileName as text

                    end if

                    set allNames to allNames & "\n" & finalName


          end repeat

          return allNames

end open

  • red_menace Level 6 Level 6 (14,275 points)
    Currently Being Moderated
    Jan 26, 2013 1:25 PM (in response to mtimmons)

    I haven't had that much luck with the Automator running menu - what OS are you running, and how are you creating your AppleScript?  AppleScript in Xcode or a Cocoa-AppleScript can put up non-modal dialogs that can include a cancel button.

  • red_menace Level 6 Level 6 (14,275 points)
    Currently Being Moderated
    Jan 26, 2013 1:52 PM (in response to mtimmons)

    If you are using Lion or Mountain Lion, a Cocoa-AppleScript can be used.  I have a Cocoa-AppleScript applet template for a progress window that has a cancel button - the example just steps through the dropped items without doing anything with them, but you can drop your code into it.  The template can be downloaded here.

  • red_menace Level 6 Level 6 (14,275 points)
    Currently Being Moderated
    Jan 26, 2013 2:18 PM (in response to mtimmons)

    The Cocoa-AppleScript application will run in Snow Leopard, but I'm not sure how the Script Editor will handle editing it in Snow Leopard, since additional Cocoa stuff was added to the AppleScript Editor in Lion.  Since the applet knows when you press the cancel button (or when it finishes), you can do whatever you need.

  • red_menace Level 6 Level 6 (14,275 points)
    Currently Being Moderated
    Jan 26, 2013 5:37 PM (in response to mtimmons)

    Breaking up your script into several smaller handlers makes things easier to work with and debug.  For example, you could put each function in its own handler (which allows for adding and changing functions), and put common tasks such as notifications into their own handlers (note that you can use Mountain Lion's Notification Center directly).


    My Progress Window template has a class in the bundle that provides various handlers/methods for common things such as changing the text fields, and these handlers are what are being called from the example script.  The class is commented fairly well (although I always welcome feedback), so you can take a look to see what is available - the example application shows how to use some of the methods, but you are free to rearrange oe replace things as desired.


    When initializing the application, you could create the progress window instance and place it into a property where it will be available in all of your handlers, then put up your function dialog.  The selected function would then be dispatched by calling the appropriate handler, where you would set up the various progress window parameters, and show the progress while processing the items.  The progress window instance can be reused by closing the window, resetting items as desired, and showing the window again.

  • red_menace Level 6 Level 6 (14,275 points)
    Currently Being Moderated
    Jan 27, 2013 8:53 AM (in response to mtimmons)

    I was also playing with your script, and the renamer part seems to work OK for me.  Errors in a Cocoa-AppleScript application are handled a bit differently than regular AppleScript, in that an error just causes the containing handler to be aborted (another reason to break up the script) - the application normally doesn't quit.  In your renamer section, the use of path to me in your dialog will not work, although it is not needed (the path to recource uses the current bundle).

  • red_menace Level 6 Level 6 (14,275 points)
    Currently Being Moderated
    Jan 27, 2013 10:28 AM (in response to mtimmons)

    That error looks like you are trying to get the name of a text string, so make sure the statement is being targeted to the right application.


    I rearranged the code from your original project to make it easier to work on, and added statements to use Mountain Lion's Notification Center.  I don't have the remote volumes, of course, but the test and batch rename parts are working - I uploaded the example application here if you want to take a look at it.

  • red_menace Level 6 Level 6 (14,275 points)
    Currently Being Moderated
    Jan 27, 2013 11:46 AM (in response to mtimmons)

    OK, I see what it is - the items dropped onto the application are sent as POSIX paths.  My original template didn't use the Finder or System Events to get the name, so I'll be updating my templates.  In the mean time, you can coerce the dropped items to aliases if they are text (the POSIX paths) - just add the following to the beginning of the open handler (someItems is the parameter name I used with my open handler):


      repeat with anItem in someItems -- coerce to alias in place (if needed)

        if class of anItem is text then set contents of anItem to (anItem as POSIX file) as text as alias

      end repeat

1 2 3 Previous Next


More Like This

  • Retrieving data ...

Bookmarked By (0)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.