Why is this working:
use AppleScript version "2.4"
use scripting additions
every document -- OK! It gets every tabs of the open windows of SD
While this one is not working:
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
every document -- error "Can’t get every document." -1728
Try with telling explicitly to which application are the documents belonging.
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
set theApp to (path to frontmost application as text)
tell application theApp
every document --> {document "Sans titre" of application "Script Editor"}
end tell
Good point, it works also without ‘use framework “xyz”’
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 8 janvier 2020 16:54:02
Thanks Yvan.
I just wonder why the addition of the use framework "Foundation, triggers the error.
Sometime the login behind AS is confusing …
Without a with framework statement, a call unhandled by the context of a script falls back to the application running the script. With such a statement, such calls are assumed to be ASObjC-related. Otherwise you’d need something like tell framework statements.
I don’t understand. Sorry, it is my lack of knowledge.
But … this script works fine:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
set the_path to "Users:ldicroce:Desktop:test.txt"
open for access (file the_path) with write permission
write "I am writing" to file the_path
close access (file the_path) -- a new file is generated.
this one doesn’t (I have tested on 2 different Macs):
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
use framework "Foundation" -- this is the only difference
set the_path to "Users:ldicroce:Desktop:test.txt"
open for access (file the_path) with write permission
write "I am writing" to file the_path
close access (file the_path)
With the following error: “Can’t make current application into type «class fsrf».”
This means that if I include the use framework “Foundation”, I have to readjust most of my scripts.
I am sure it is not the case, then I am doing something wrong.
In fact all your script use a “not really good” syntax. Here are the correct ones.
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
set the_path to (path to desktop as text) & "test.txt"
set theFileRef to open for access (file the_path) with write permission
write "I am writing" to theFileRef
close access theFileRef -- a new file is generated.
With a small change
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
set the_path to ((path to desktop as text) & "test.txt") as alias
set theFileRef to open for access the_path with write permission
write "I am writing" to theFileRef
close access theFileRef -- a new file is generated.
When we use a framework, several commands no longer apply to alias objects. We must use «class furl» ones.
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
use framework "Foundation"
set the_path to ((path to desktop as text) & "test.txt") as «class furl»
set theFileRef to open for access the_path with write permission
write "I am writing" to theFileRef
close access theFileRef -- a new file is generated.
Worse, some applications, Adobe ones, require «class furl» objects even if we don’t use frameworks.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) jeudi 9 janvier 2020 12:08:07
Yvan’s given you workarounds. It’s basically a bug in AppleScript when building file (and sometimes alias) specifiers – you need to use coercions instead.
I see… I wasn’t aware of this bug.
And thank Yvan for the suggestions.
L
An alternative that seems to work in many circumstances where a «class furl» object or AppleScript alias is expected is the file’s POSIX path. Since POSIX paths are easy to work with, I’ve gotten in the habit of trying that option first to see if it works with a given command. Here is its application to Yvan’s example (remember not to include a file keyword before the POSIX path):
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
use framework "Foundation"
set the_path to ((path to desktop as text) & "test.txt")'s POSIX path
set theFileRef to open for access the_path with write permission
write "I am writing" to theFileRef
close access theFileRef
The problem is that the fact that POSIX paths are accepted by such command has never be officially stated. We may see one day where it fails.
The dictionary of Standard Additions claims : open for access file : the file or alias
a «class furl» object matches this statement.
set p2d to path to desktop as text
set p2d to p2d as «class furl»
--> file "SSD 1000:Users:**********:Desktop:"
As far as I know, POSIX Path doesn’t.
So, as I was thought that “playing with matches” was not good practice, I wouldn’t rely upon that.
In fact I flee POSIX path or Finder like the plague.
«class furl» objects are definitely the ones to use.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) vendredi 17 janvier 2020 18:03:47
I too avoid the Finder whenever possible, because I’ve gotten spurious results in a number of different circumstances over the years. On the other hand, I don’t have an aversion to using POSIX paths based on 10+ years of heavy use without ever encountering a problem (once I’ve confirmed that a given command accepts POSIX paths, of course.) But I do agree with you that their use is not documented and could break some day.
With scripting addition commands, that’s possibly a reasonable approach. For anything involving an application, however, it’s something that caught a lot of people out when sandboxing arrived.
Given the trend in security, passing file objects – which arrive at applications with a certain level of implied authorization – seems to me to a much more future-proof approach, as Yvan says. It’s not as if there’s any great coding burden involved.
Despite using POSIX paths successfully for years, you guys have convinced me to make the switch. As you say, file objects aren’t hard to code.