Compiling for Other Macs

I’m stumped. I’ve tried the “Double Tell” and the “Launch By Creater/ID” and they both behave exactly like if I did a normal Tell statement…I still have to recompile for every other Mac I install the script on. Here’s the relevent code with the “Double Tell” for example:

	if gRealExtention is "EPS" then
		tell application "Finder"
			set appPath to application file id "8BIM" as string
			set appName to name of application file id "8BIM"
		end tell
		
		launch application appPath
		
		tell application "Adobe Photoshop CS"
			tell application appName
				open file fixFilePath
				
				--execute JavaScript control of Photoshop
				--acquired with ScriptingListener plugin per Adobe guidelines
				do javascript (gPathToScript as alias)
				
			end tell
		end tell
	end if

Here’s the ID launch version:

	if gRealExtention is "EPS" then
		tell application "Finder" to set appName to name of application file id "com.adobe.Photoshop"
		tell application appName
			using terms from application "Adobe Photoshop CS"
				open file fixFilePath
				
				--execute JavaScript control of Photoshop
				--acquired with ScriptingListener plugin per Adobe guidelines
				do javascript (gPathToScript as alias)
				
			end using terms from
		end tell
	end if

And here is the code before I tried all this fancy stuff:

	if gRealExtention is "EPS" then
		tell application "Adobe Photoshop CS"
			open file fixFilePath
			
			--execute JavaScript control of Photoshop
			--acquired with ScriptingListener plugin per Adobe guidelines
			do javascript (gPathToScript as alias)
			
		end tell
	end if

The third (last) chunk of code works just fine on my machine, but has to be recompiled on every other machine I put it on (really annoying). I stumbled on the “make it work on any machine” hints (first two above) but despite compiling and running fine locally, they still require a recompile when moved to other Macs.

I’m obviously missing some details, since I get the impression either of these techniques should have worked. :frowning:

I can post the surrounding handler this statement lives in, or the entire script (very long!) on request.

Model: Dual 1.8 GHz Dual PowerPC G5
AppleScript: 1.9.3
Browser: Firefox 1.5.0.1
Operating System: Mac OS X (10.3.9)

When using the techniques you describe, I use allways the “path” (instead of the “name”) as the “tell” target → ie “appPath” instead of “appName”

And it allways worked for me. Not sure at this point, though, why I chose the path against the name. Maybe the rest of the script has something to do with the wrong behaviours your experiment???

Gave that a whirl, didn’t change a thing. :frowning:

This one snippet of code is the only place Photoshop is even referenced. Everything else is Finder tells.

Maybe this is a dumb question, but do I need to “abstract” all my Finder tells in a similar fashion to make it all work?

What does it mean, BTW, you must “recompile” the script in other machines? What is the behaviour in those other machines?

Means I copy the script to another Mac, then have to open it in Script Editor and Save As. to force it to recompile before it will work.

Otherwise, dropping folders on the script (using the “on open” handler) does absolutely nothing. No error, no activity, no launch, nothing.

:frowning:

Yah! :lol:

This seems a totally different issue (permissions issue). I only know a problem causing these symptons: bad permissions or corrupted files.

I don’t know how you “transmit” the files to the other machines, but you should try enclosing them in a .dmg image file. This should preserve all the files’ features: executable bits, resource fork, etc.

→ My experience with this issue comes from the StuffIt Engine 8.0.0 (installed by StuffIt and other coetaneous tools, such as Virex [I forgot the version]). This engine would just mangle permissions at un-compression time, being the main cause for “no launch/no icon bouncing in dock” errors. May be, of course, different reasons: not-macintosh-friendly CD format, transmission thru a Windows network, etc.

The only problem I see with that theory is that all our Macs are rigorously maintained, including permissions, and all profiled from a standard image. :frowning:

The files are trasnsmitted via a server (copy to server, copy from server). The server is an XServer. Never have problems with other drag-n-drop apps and files.

But heck, I’ll try anything…how do you make a DMG file?

Oddly, we’ve never had this problem, and we have much more strict permissions control that most folks at the workstation level. If anything, Apple’s installers make the biggest mess of things, generally. They have a bad habit of “undoing” our careful work. It’s why we lock-down the Applications folder to keep users from installing stuff and keep Apple’s updaters off. We test offline, then reprofile machines manually. :wink:

In case Walter is watching, I do appreciate the help. I want to give the DMG thing a try, just don’t know how. :slight_smile:

I said “dmg”, but you may try whatever file-enclosing method able to preserve all meta-info. I like “.dmg” files, but you may use as well OS’ built-in zip options (ctrl+click => create compressed archive; then use BOMArchiveHelper in the target machine to uncompress the resulting .zip) and something else.
To create a .dmg file, place your applet/droplet inside a new folder. Launch Disk Utility (/Applications/Utilities) and select “new image from folder” (File menu), then the new folder containing the stuff. Choose name and settings (default ones are usually OK) and save to your favorite location.
And report back! :wink:

For me it was Images–>New–>Image From Folder…

After a few test installs on other workstations, I think this worked. Copied from station to station via the Disk Image file seems to do the trick.

Things like this really bug me about Apple’s implementation of *NIX permissions. :stuck_out_tongue: