Scripting Additions Conflicting with Cocoa

AppleScript
#1

I’ve recently added use framework "Cocoa" to be able to customize the included AppleScript progress window (disable the Stop button and hide the window while the script is still running) to some already existing scripts of mine.

I noticed a few new issues where some things started not working which used to work fine. This lead me to these two posts:

set volume issue with Cocoa: https://stackoverflow.com/questions/15555380/set-volume-not-working-in-xcode-with-applescript-cocoa-objc

open for access issue with Cocoa: "open for access" error in modern AppleScript

Both of these posts have good information about this issue, and both are fixable by using tell current application, but I’m curious if there are anymore know Scripting Additions commands (or any other AppleScript stuff) that have issues when using Cocoa.

I figured if anyone knows the rhyme or reason or has a list of known conflicts, it’d be the folks on here.

I’m plan on doing a full audit on the scripts where I recently added Cocoa, but I figure it’d be a lot simpler to just have a list of known issues like these to look out for when using Cocoa in AppleScript.

Thank you all!

#2

Does your script have a

use scripting additions

line? If not put that at the top whenever you have a

use framework x

or 

use library y
#3

Yes, it does. All the scripts have the normal header that Script Debugger includes. And the use framework "Cocoa"

#4

I can’t think of any others off the top of my head.

#5

When framework “Cocoa”'s used, set volume works with the now-deprecated small integer direct paramer (0 - 7), but doesn’t understand the more modern labelled parameters.

I’m not seeing any problem with open for access.

#6

I think that’s a reference to the file specifier issue.

#7

That’s why I wasn’t seeing it. :wink:

#8

@ShaneStanley, so does that mean that the AppleScript compiler looks for terms starting at the top of the list?
IOW, does that mean that by putting use scripting additions at the top that your script will use those terms before it tries to use terms from the lower “use” statement?

Thanks.

#9

Thanks everyone!

@NigelGarvey Sorry I wasn’t clear about the open for access issue. It is actually about the file specifier. Also, good to know that the old style set volume (0-7) works as an option as well!

I also found that tell application "Finder" to make new folder at (POSIX file "/Some/Existing/Path") with properties {name:"Testing"} fails when Cocoa is used. But seems to work with the as «class furl» fix, such as tell application "Finder" to make new folder at ((POSIX file "/Some/Existing/Path") as «class furl») with properties {name:"Testing"}

#10

Found some more info about the issues alias, POSIX file, file, and date.

http://www.macosxautomation.com/applescript/apps/gotchas.html

Hopefully this thread can be a collection of useful information for others running into the same issue.

#11

With this new info, the better fix for my Finder code issue is tell application "Finder" to make new folder at ("/Some/Existing/Path" as POSIX file) with properties {name:"Testing"}

#12

Turns out my open for access issue actually had to do with using POSIX file as well, which can be fixed more cleanly with coercion instead of using «class furl» or tell current application as described in the previously linked Gotchas pdf. Such as: open for access ("/Some/Existing/Path/Testing.txt" as POSIX file) with write permission

#13

Where it’s positioned doesn’t alter the loading order.

1 Like
#14

@ShaneStanley Just noticed you wrote the PDF that I linked to :smile:

It looks like that was the “Gotchas II” section from “AppleScriptObjC Explored” which is no longer available (http://www.macosxautomation.com/applescript/apps/book.html).

Are there anymore useful gotcha’s in the “Gotchas I” section from “AppleScriptObjC Explored”? Or is this stuff now covered in “Everyday AppleScriptObjC”, which is still available at: https://macosxautomation.com/applescript/apps/everyday_book.html

#15

No — they were all specific to AppleScript in Xcode projects.

#16

Thanks so much! It’s great to have peace of mind that there are no other sneaky issues when using Cocoa.

I’m curious, is there any downside to always coercing path strings with as POSIX file? Because of consistency, I’d rather always write ("/Some/Path" as POSIX file) instead of only doing that when using Cocoa and writing (POSIX file "/Some/Path") when not using Cocoa.

#17

No, it’s fine to use that form all the time.