Thanks you in advance and and may the Lord Jesus Christ bless you for your help,
I have been having troubles with I believe coercion and variable scope. I get something working as a script, then I save the script as an application and things no longer work. The following is an example, It works fine as a script but when I save it out as an application it no longer functions.
I end up spending hours on a single issue trying to “display dialog someVar” or “display dialog class of someVar” all over my scripts to try to figure out what in the world is going wrong.
Can anyone point me in the right direction to figure out what I am doing wrong.
--USE: Check if an item exists. IE. File or Folder
--Requires: Alias to item
--Returns: true or false
on checkFolderExists(folderPath)
--set msg to "The Folder Does Not Exist"
set msg to false
set Mypath to ""
try
tell application "Finder"
set Mypath to folderPath as string as alias
if exists Mypath then
--set msg to "The Folder Does Exist"
set msg to true
end if
end tell
on error
return msg
end try
return msg
end checkFolderExists
display dialog checkFolderExists((path to desktop folder) & "1234_Desc")
P.S. I don’t know if this matters but I am working to keep my code modular. When I am done I will be calling a handler using the returned value of this handler IE.
@ gannet, Thank you, I will give that a shot for sure. I had something similar but my guess is i had some syntax wrong because if the folder did not exist I would get an error saying the alias did not exist.
which brings me to my next question…
@ Adam Bell, how could I have found that answer on my own? I feel like often times I am just trying different things in different orders and trying to use coercion to a different type. Is this a topic I could look more into such as “proper syntax”?
Lastly this still does not resolve the problem of moving code from scripts to applications and why I find them break. I may have to give you more code but it is broken at the moment because I was working on a different part so I don’t have a good example to give to you.
To recap I have 2 questions, one to Adam or any one to help me learn proper structure. Secondly I am still having issues when I create a script file and have it working fine, when I save it out as an application it seems to break. Does anyone know what things are handled different between the two. I am leaning toward a scope issue, once it is saved as an application things are changing levels slightly in hierarchy?
Thanks again! May the Lord truly bless you and show you his salvation!
To answer the question you directed at me, your preamble said that you needed an alias. (path to desktop folder) returns an alias, but “1234_Desc” is just text. You cannot concatenate something that is not an alias to something that is so you have to do that separately as I showed; concatenate two strings then convert. “alias” in my correction converts the whole inner concatenated string to an alias.
the main difference between application and script is that for example the current application (highest object in the parent chain) is different between those two. When working in an unsaved script in script editor the current application is script editor while running it as an application the current application is itself.
for example: when creating a new script, and don’t save it, path to me is the path to the script editor application but when you saved it as an application path to me is the path to the script application and not script editor itself.
so in general I’m aware of these differences between scripts and appliations.
It works both as a compiled script and as an application on my machine and therefore offers no clue as to what’s causing your problem.
As Adam’s pointed out, the call to the handler is passing a list containing an alias and a text, not text representing a path. However, the coercion ‘folderPath as string’ within the handler corrects this ” UNLESS AppleScript’s text item delimiters are set to anything other than their default value, in which case you’ll still get a path, but the item name at the end of it will be prepended with whatever the delimiter value happens to be at the time.
The mere act of coercing the above result to alias is enough to test the existence of the item represented by the path, since trying get an alias to a non-existent item generates an error and the script execution jumps to the ‘on error’ statement. This makes the ‘if exists’ statement superfluous, since it’s not executed if the error occurs. This in turn makes the use of the Finder superfluous, since its only purpose here is to provide the ‘exists’ command.
The scriplet feeds the boolean returned by the handler directly to a ‘display dialog’ command. It happens to work, thanks to some implicit coercion of the boolean to text, but non-text values should really be explicitly coerced to text before being passed to ‘display dialog’.
on checkFolderExists(folderPath)
try
folderPath as alias
set msg to true
on error
set msg to false
end try
return msg
end checkFolderExists
display dialog (checkFolderExists((path to desktop folder as text) & "1234_Desc") as text)
There’s essentially no difference between a script being run by its own application (ie. “running as an application”) and one being run by a separate application like Script Editor. Any difference will be in the application itself.
To take this contrived example:
set myPath to (path to me as text)
tell application "Finder" to set myClass to (class of file myPath) as text -- Coerce the class to text.
set isAppFile to (myClass is "application file") as text
display dialog isAppFile
The displayed result is “true” when you run this in Script Editor and “false” when you run it as an application. This is because Script Editor has access to the terms in the FInder’s scripting dictionary and coerces the class returned by the Finder to text (in the second line) as “application file”. When run as an application, the script only has access to the compiled class token, which, as text, is “«class appf»”. Obviously you get round this by not coercing things to text unnecessarily.
Other considerations include the fact that running a script applet usually brings it to the front, which can cause problems if you want it to do something with what was the frontmost application before you ran it. Also script applications take longer to communicate with other applications and their run time includes the time it takes them to launch and quit.
Just to clarify the ‘path to’ thing a little:
‘path to current application’ and ‘path to me’ used to return the same thing: namely an alias to the file containing the application running the script. But sometime between Mac OS 10.2 and the present, ‘path to me’ was changed (in response to popular demand) to return an alias to the file containing the script itself.
Thus, in a script running as an application, ‘path to current application’ and ‘path to me’ still mean the same thing. But in a script being run by a separate application ” such as Script Editor ” even if the script itself is saved as an application ” ‘path to me’ returns the script file, ‘path to current application’ returns the running application file.
Just some additional info, in this PDF document you can find that path to me has changed multiple times from 10.3 through 10.5. The release notes from Apple can be useful when working with older systems.