Script breaks in 10.4 Tiger if saved from 10.5 Leopard Script Editor

I have a large script (saved as an application bundle) for our inhouse workflow that until this week as being written using a 10.4 machine. I recently got upgraded to 10.5 (but not everyone else has or will be for awhile).

When I save my script from the newer version of Script Editor (2.2 - AS 2.0.1), it breaks the script for the 10.4 users, but works fine for 10.5. If I make no changes but open and save it using the 10.4 version of Script Editor, it works fine for both 10.4 and 10.5 users. If I then open in, make no changes, and save it again from 10.5, it again breaks for 10.4 users.

Another weird thing I noticed - the script is saved as an Application Bundle, and contains other scripts inside the package. However, any time I open it up in 10.5 Script Editor, the “Bundle Contents” icon is grayed out, and when I choose save as, it always defaults to “Application” (not bundle) and has the startup screen checked. I can’t get it to where it will stay a bundle. What’s with that?

Does anyone know in general what could be going on? As I weed through the script, I’ll try to see if a particular line is what’s breaking and post it (most of it works, just dies at one part), but I though someone might know of an overall change that’s leading to this.

OK, here is at least the first area of code that is causing problems for 10.4 users when the script is saved from 10.5


set jobPath to (path to desktop as text)
set templateToOpen to "type1"
set pathToOpen to "fileserver:templates:"

tell application "Finder"
	duplicate (file 1 of (pathToOpen as alias) whose name begins with templateToOpen) to jobPath
	open (file 1 of (jobPath as alias) whose name begins with templateToOpen)
end tell

This generates a “Handler can’t handle an object of this class” error.

if I change the bottom half to


using terms from application "Finder"
	duplicate (file 1 of (pathToOpen as alias) whose name begins with templateToOpen) to jobPath
	open (file 1 of (jobPath as alias) whose name begins with templateToOpen)
end using terms from

and save it in 10.5 and run it in 10.4 I get a "Can’t get file 1 of alias “fileservertemplates:” error message.

This part of the code was not written by me, and I’m trying to not change it too much, but it looks like something in it is not compatible with the changes between the 10.4 and 10.5 versions of applescript. Does anyone know how to change this so it will work in both versions of the OS?

I would have normally written this by looping through the files within pathToOpen until it found one that started with templateToOpen and go from there, but I’m trying to make minimal changes to this part of the script if possible, not to mention that all of my other code that loops through any folders on our server is currently causing the script to slow waaay down when run 10.5 (separate issue).

Hi,

sorry, the code is quite amateurish :wink:
try this


-- set jobPath to (path to desktop as text)
set templateToOpen to "type1"
set pathToOpen to "fileserver:templates:"

tell application "Finder"
	try
		set newFile to duplicate (file 1 of folder pathToOpen whose name begins with templateToOpen) to desktop
		open newFile
	on error
		-- do some error handling if no file matches the given string
	end try
end tell


Note:
using terms from is only needed, if the targeted application isn’t specified with a literal string like


set f to "Finder"

using terms from application "Finder"
	tell application f
		get name of folder 1
	end tell
end using terms from

the compiler can resolve the terminology of the targeted application at compile time
At run time the code will be ignored

Thanks for the cleaner version :wink: - I like that much better, and will be able to use that in other ways instead of my looping way as well. So I’m fixing something and learning something at the same time…

However, I’ve realized the problem I’m having between 10.5 and 10.4 is still there. The duplication didn’t actually happen to the desktop - and when I try to plug in the actual folder location, it gives me the “Can’t handle objects of this class” again when run in 10.4


set jobPath to "fileserver:jobs:job1" as text
set templateToOpen to "type1"
set pathToOpen to "fileserver:templates:"

tell application "Finder"
	open jobPath
	try
		set newFile to duplicate (file 1 of folder pathToOpen whose name begins with templateToOpen) to jobPath -- jobpath seems to be where the error is now
		open newFile
	on error
		-- do some error handling if no file matches the given string
	end try
end tell

the problem could be, you try to duplicate a file to a string path not to a folder

set jobPath to "fileserver:jobs:job1" -- as text <-- a literal string IS text
set templateToOpen to "type1"
set pathToOpen to "fileserver:templates:"

tell application "Finder"
	open jobPath
	try
		set newFile to duplicate (file 1 of folder pathToOpen whose name begins with templateToOpen) to folder jobPath
		open newFile
	on error
		-- do some error handling if no file matches the given string
	end try
end tell

But I’d recommend to use the shell for file moving files from or to a shared volume

I’ll have to check for sure when I get to the office, but I’m pretty sure I tried that (adding “folder”), and it too generated a “Can’t handle objects of that class” error in 10.4 when I saved it from 10.5 (works as expected when run in 10.5 though)

I was wrong…ading folder works in both versions. Thanks so much!

I’m still confused by the fact that all scripts open with the “Bundle Contents” icon grayed out and defaulting to saving as “application” always…anyone kow what’s going on there?

What happens, if you copy the code in a new script?

This is a known bug, admitted to by Chris Nebel of AppleScript Engineering on the applescript-studio mailing list. Scripts compiled in Leopard with “using terms from” will not work in Tiger.

Please report this problem on bugreporter.apple.com so that they know this is important to fix.

Chris reports a work around using a hex editor, but I haven’t tried it. Presumably it would mean changing these bytes every time you re-compile a script or studio application.