Get Info Question

I’m finishing a shareware app that has to open in Reader. Mainly, I don’t want users to open the app in Acrobat. I found a solution that works - I use a kill_pid script someone gave me - kill acrobat pro - and then force adobe reader to open the main file. This works but it’s cumbersome. I tried other things like coercing Reader to open an alias but the solution I’m using is the best strategy so far.

I was just wondering, does anyone know, is it possible to use applescript to lock – ‘open with’-- in ‘get info’ for a particular file? In other words, is there some way to write a script that would prevent users of my app from changing the default application, for my main application file, in get info, to acrobat? I’m no programmer, I just dabble here and there. I checked out the resources I have, and it doesn’t seem like this is possible. But I thought I would ask the developers on this forum. Thank you much.

No you cannot do that, but I don’t think it’s what you’re looking for. The console user (the currently logged in used into the Desktop) is always free to change launch services settings in userland. Then at any given time the root user is able to change default application settings in launch services system wide. There is no locking involved at all, it’s a free for all world.

Files are opened using AppleEvents in Mac OS X systems. Most common is of course the open AppleEvent which is named the same in AppleScript. I only have Adobe Acrobat Professional so this is what I would use:

set appName to "Adobe Acrobat Pro"
tell application appName
	open "/Users/me/Desktop/test.pdf"
end tell

The reason I put the application name in a variable is to prevent that the script always launch the application, I only want to launch the app when the scrip runs. The reason I don’t use a using terms from application block is because the open command is not part of the application but is an AppleEvent handled by the system (if other readers wonders why I didn’t do that). Alias is no longer supported by Adobe software (most software to be honest) because it’s outdated. You could use a file specifier or a plain HFS pr POSIX path, whenever possible I use posix paths because HFS are somewhat odd these days and has an more uncertain future than POSIX paths.

Alias still works fine with Adobe software here, and it’s still the recommended approach. What other software do you see it failing in?

set appName to "Adobe Acrobat Pro"
set thePath to "Macintosh HD:Users:shane:Desktop:Automator Script Path.pdf"
tell application appName
	open alias thePath
end tell

You can’t use paths with sandboxed applications – yo have to use a specifier or alias.

Let me rephrase: It doesn’t work consistently, so deprecated should be the correct term? We’re having problems in batch processing with aliases since Indesign CS5 and more users back then. The solution: Use specifiers or strings and no longer alias objects was the advice back then.

I haven’t tested it as an specifier as you posted but I meant simply an alias object. I’m not surprised it works because an alias specifier contains plain text HFS path and not the actual alias data. So the object to be resolved is a unicode string containing an HFS path which seems to work fine directly as an argument too. The object you’re sending is not an alias but an object that can be resolved into an alias if required.

You can use paths in sandboxed applications but Cocoa Scripting will break it down for you. It’s not the path itself that is not allowed, only when you make an Cocoa application scriptable, let Cocoa do the “binding” for you and when you use “file” as an type. It’s not a matter of “can’t”. it’s a matter what tools you use to make your cocoa written application scriptable. Therefore I’ve seen, both in sandboxed and non-sandboxed apps, that apps use the “any” type (or non existing types) for file path arguments to avoid unwanted/unnecessary code to be executed.

Odd, because I’ve got people running old code full of them with no problem. However, you’re right that InDesign is happy with just paths – it doesn’t use Cocoa scripting. But I think Acrobat does.

I think you’re missing the point. When you pass a file object, AppleScript passes a security-scoped NSURL, which gives the sandboxed app permission to access the file. If you pass just a path, unless the app already has permission to access that file, the sandbox will refuse it access. It’s not a scripting issue – it really is a matter of “can’t”. See the AS release notes for OS X 10.8.

Try this:

tell application id "com.apple.TextEdit" -- TextEdit
	open "/Users/shane/Desktop/Test.txt"
end tell

Hello Shane

The first time I ran a modified version matching my settings :

set thePath to POSIX path of ((path to desktop as text) & "General Lib.txt")
--set thePath to POSIX file thePath

tell application id "com.apple.TextEdit" -- TextEdit
	open thePath
end tell

I got an alert claiming that I hadn’t permissions to open the file.
[format]Le document « General Lib.txt » n’a
pas pu être ouvert. Vous n’avez pas
l’autorisation.

Pour afficher ou modifier vos autorisations,
sélectionnez l’élément dans le Finder, puis choisissez
Fichier > Lire les informations.[/format]

I didn’t took care of the “instructions”
but I added the instruction defining a POSIX file and of course it works.
I’m puzzled because now the original version open flawlessly every files on the Desktop.

Yvan KOENIG running Sierra 10.12.4 in French (VALLAURIS, France) jeudi 30 mars 2017 12:05:52

I’m not sure why it works with every file there, but once a sandboxed app has been given permission to access a file, I believe it retains it (I’m not sure how long for, in the absence of storing a bookmark).

I think so too :slight_smile:

Apologies for the late reply. (Being a forever-dabbler in apple script) I followed most of what everyone said - wanna clarify. My goal is to have reasonable certainty that my file is opened with reader and not acrobat, under the worst conditions, which are: A savvy end-user opens acrobat, closes reader, changes “open with” in ‘get-info’ of the main file to acrobat pro. Even under these conditions, my script still opens the main file with reader. If a user does that, acrobat launches, but my file is read by reader. (There’s more to it than I’m getting into here, re a pw input etc. but that’s irrelevant to this discussion).

A comment: Acrobat Pro ramrods itself into AS (my cynical view is that Acrobat = $ in Adobe’s wallet). When you go to the AS dictionary and glance at what Reader can do, compared with Acrobat, Reader is near-empty. DJ BW’s script works for Acrobat but I’m not sure it does for Reader. Similar story for POSIX path scripts, & using the app id. When I’m writing an apple script and write the term, Adobe Reader, if Acrobat is open, when I compile, “Adobe Reader” automatically changes to “Adobe Acrobat Pro.” I have to close Acrobat, “Reader,” compile and then, save as an app to ensure Reader opens my file.

My system is currently crashed and so, can’t test anything right now but was curious, DJ BW’s script uses “me.” Is that a universal term that can be used by “Any_User” to open their home folder?"

My fix, btw: I I kill Acrobat Pro, tell app Reader to launch right before I "tell app Finder to open file myfile of my Folder1 of myFolder2 of folder Library of home using app Reader.app of folder App of startup disk. Took me weeks of testing to figure it out because of Reader’s limitations in AS. Thanks for discussing my issue, it confirmed my solution. (Sorry if I used the wrong lingo, I’m no programmer (shrug))