I have a 3rd party app that has the ability to run any application after it has completed a task. I chose an “Automator Application” that I created stringing some Automator Actions together.
So I am attempting to have a file passed from the 3rd party app to the “Automator Application” which has only one action associated with it since I am doing troubleshooting at this point. It is the “Run Applescript” action. Here is what I have:
property ScanSnap_Folder_Processed : "HD:ScanSnap:Processed:"
on run {input, parameters}
local stringOfCurrentDate
local fileFolder
set stringOfCurrentDate to createStringOfCurrentDate()
set fileFolder to ScanSnap_Folder_Processed & ¬
stringOfCurrentDate & ":"
display dialog the class of item 1 of input as string
--note: class of input is list
--note: class of item 1 is alias
tell application "Finder"
save (get item 1 of input) in folder fileFolder
on error
make new folder at folder ScanSnap_Folder_Processed ¬
with properties {name:stringOfCurrentDate}
save item 1 of input in folder fileFolder
end try
end tell
return input
end run
on createStringOfCurrentDate()
set currentDateFilename to ((get month of (get current date) as integer) as string) & "_" & ¬
(get day of (get current date)) & "_" & ¬
(get year of (get current date))
return currentDateFilename
end createStringOfCurrentDate
Well, you can see what I am trying to do here. And just to be sure, I save the file in a directory that has the current date, and if the directory does not exist, I create it.
For me, I think it’s a breakdown on handling the alias. I am not very versed with them. So some counsel would be appreciated.
From your introduction, I 'd say it is all very much up to whether your third party app (with or without Automator) is (script-)able enough to save its document to the constructed date-folder (or either temporary elsewhere).
Either the app is able to do so, and you could use the Finder to construct the date folder and to move or copy the document there (if you can reference it via a predertermined name, date or attribute that Finder will understand).
Else the app (even with Automator) isn’t able to save its document in any predictable way but then I don’t see how you could use / misuse Finder to overcome that inability.
In that case, I would try UI scripting instead like
tell application "System Events"
tell process ThirdPartyAppName
click menu item "Save as." of menu "File"
keystroke "Desired Filename"
keystroke return
end tell
end tell
or appropriate.
From your script, I try to understand why you’d use Finder to save a doc that belongs to another app and I just can’t imagine that to work, even if you were to reference it properly. Applications should have their own save routines and if njet so, Finder is not an assistant…
Previously, I had an Automator Application setup using only canned Automator Actions. It would name the file passed from the 3rd party app and save it to an assigned spot. Now, rather than save to a “static” folder, I would like to save the file into a folder that has the date on which I run this process. Does this help clear up the problem I am trying to solve? Please let me know if it does not.
There’s a try line missing from your script. I don’t know if that’s one of the problems or just a typo while posting.
The file will already have been saved by your application. You need to tell the Finder to move it to the folder.
property ScanSnap_Folder_Processed : "HD:ScanSnap:Processed:"
on run {input, parameters}
local stringOfCurrentDate
local fileFolder
set stringOfCurrentDate to createStringOfCurrentDate()
set fileFolder to ScanSnap_Folder_Processed & ¬
stringOfCurrentDate & ":"
display dialog the class of item 1 of input as string
--note: class of input is list
--note: class of item 1 is alias
tell application "Finder"
try -- NB.
move (item 1 of input) to folder fileFolder -- NB.
on error
make new folder at folder ScanSnap_Folder_Processed ¬
with properties {name:stringOfCurrentDate}
move (item 1 of input) to folder fileFolder -- NB.
end try
end tell
return input
end run
on createStringOfCurrentDate()
set today to (current date)
set currentDateFilename to (((month of today) as integer) as string) & "_" & ¬
(day of today) & "_" & ¬
(year of today)
return currentDateFilename
end createStringOfCurrentDate
As it stands, this only handles one file at a time. If you change ‘item 1 of input’ to simply ‘input’, it’ll perform a bulk move with any number of files that are passed to it in one go. This is academic, of course, if your application only passes it one file at a time anyway.
I will certainly give this a shot. (Sorry, right now I am heading out the door.) Move’ing the file is exactly what the previous Automator Action I had in place did and so it sounds logical that what you have here will work. That said, I am wondering if technically, save’ing the file in a folder would still be permissable, rather than move’ing the file to a folder.
Although we often talk loosely about “saving a file” somewhere, the precise purpose of the save command is to save a document that’s open in an application. The document is saved in a file, which is created if it doesn’t already exist. save is an application command, which means it’s up to application developers to implement it in their applications in a way that’s relevant to the apps concerned. The Finder doesn’t deal in documents and so doesn’t have a save command. (The term itself is a standard one though, so it still compiles.) With applications that do have a save command, the proper destination for the in parameter is the file in which the document is to be saved. This will normally be in the form of a path or a file specification, since an alias can only be used where the file is known to exist already. With many apps, the command is implemented in the knowledge that people are likely to confuse “saving a document” with “saving a file” and, if the destination specified is a folder, will attempt to handle the situation intelligently. But I learned the hard way a few years ago when an attempt to save a document to my desktop resulted in the loss of my Desktop folder! :rolleyes:
First off, thank you for the through explanation. I appreciate it.
Now, let’s see if I can recall all the observations I made from my work last night. And, with regard to #2 below, if anyone has any suggestions on what to do, please let me know:
The “Run Applescript” action seemed to have the potential to behave differently if one would not explicitly compile the code (using the little hammer button in the action) before saving the Automator Application file. The code I supplied, I am 95% sure, was correct syntax, etc., etc. And when I ran it, it errored out. I couldn’t see the error (see #2) though! I then compiled the code and resaved the Automator Application.
No error. Hrmpf!
There is no easy way to see what your errors are. If you save the Automator Application, and then use it as a droplet, if there are any errors, they pop up briefly and do not allow the user the opportunity to view the error (it flashes and then disappears abruptly). How can one get the error to persist on the screen?
I found that when I used Nigel’s code above, that the filename in the new location turned out to be “originalFilename” & “some 10 digit number.pdf”. What’s up with that? I then changed the code such that a variable was set to item 1 of input. This changed the filename such that it was now the original filenmame. Great! But why…?
That is all the observations I think I wanted to share at this time, but if I come up with others, I will post them. This foray into using Applescript with Automator has some nuances, particularly #2, that can cause some grief, but when it all comes together, it’s a nice thing.
By the way, is this the right spot to be posting this type of question? I noticed the Automator sections, but thought these questions were more Applescript-specific.
I’m not seeing that here. The script seems to work whether I compile it before saving the workflow or not. But it doesn’t hurt to get into the habit of compiling before saving. It’ll show up any mistakes that can’t be compiled.
Wrap the code in a try block and use display dialog to display any error messages:
property ScanSnap_Folder_Processed : "HD:ScanSnap:Processed:"
on run {input, parameters}
local stringOfCurrentDate
local fileFolder
try -- To catch any errors.
set stringOfCurrentDate to createStringOfCurrentDate()
set fileFolder to ScanSnap_Folder_Processed & ¬
stringOfCurrentDate & ":"
tell application "Finder"
try
move (item 1 of input) to folder fileFolder
on error
make new folder at folder ScanSnap_Folder_Processed ¬
with properties {name:stringOfCurrentDate}
move (move item 1 of input) to folder fileFolder
end try
end tell
return input
on error errMsg
-- If an error's thrown while the script's running, display the error message.
-- If you like, you can add more information to the message,
-- such as the name file and/or of the folder.
display dialog errMsg
end try
end run
on createStringOfCurrentDate()
set today to (current date)
set currentDateFilename to (((month of today) as integer) as string) & "_" & ¬
(day of today) & "_" & ¬
(year of today)
return currentDateFilename
end createStringOfCurrentDate
Beats me. It always works properly for me. I don’t know how your “3rd party app” is using the Automator application, but I can’t see that that would make any difference.
