Why is AS so incredibly bad at casting?

Scripting Forums AppleScript | Mac OS X
,
#1

I spend about 90% of my AS debugging time dealing with variable types. AS is constantly telling me that it cannot convert one type of variable into another. Yet I read that “AS is very good at converting between variable types”. Well, it sure isn’t in my experience; it’s extremely finicky. No other language I’ve used is so frustrating with regard to convering strings to aliases to file references.

Much of the problem is that when an error occurs, AS often does not tell what type of variable it was/is expecting. Right now I’m getting a “Can’t make some data in to the expected type” error. Really–that’s the whole error. Why on earth did Apple choose to withhold the type of data AS was expecting so the programmer could quickly and easily solve the problem?? “Expected alias, received string” would make a world of difference.

Is there any way to make this easier? (I’ve tried Script Debugger and did not find that it helped much–it doesn’t give any more insight with these errors than Script Editor does.) Dealing with this issue is wasting so many hours of my time that it’s making AS much less likely to be used in our department.

Thanks for putting up with my rant–this has been building for quite a while. I appreciate any thoughts,
-Kurt

#2

ktappe,

Post the part of your code that you’re having problems with so we can see what is going on.

PreTech

#3

OK, here are the lines that lead to the current error:

	set theCheckinFile to (a reference to file checkinName)
		
	set destItem to first paragraph of (read theCheckinFile)
		
	tell application "Finder"
		delete file theCheckinFile
	end tell

The “delete file theCheckinFile” line elicits the “Can’t make some data into the expected type” error.

Casting theCheckinFile as other types including alias and string did not help.

I included line 2 just in case the file is being left open or something, but I didn’t think reading from the file would leave it undeletable nor lead to a “type” error.

Thanks for any thoughts,
-Kurt

#4

ktappe,

I’m not sure about the reference to line. I know others here will be able to explain them exactly, but here’s what I can make of the code you show.

I’m not sure where the checkinName is specified in your code. I used a SimpleText doc to play around with this. It seems to me that it must be something similar to this:

set checkinName to file “dadada” of desktop (or elsewhere)

then you want to reference it but it looks un-necessary from here. Instead maybe. . .

This assumes that checkinName has been defined somewhere in the script.



set destItem to first paragraph of (read checkinName)

tell application "Finder"
	delete file checkinName
end tell

This seems to work with a SimpleText file on my computer (other than it getting a lot of stuff before the actual text I wrote). If theCheckinFile and checkinName are supposed to be one and the same it shouldn’t matter which one is used and deleted.

Best I can do without knowing what it is you’re trying to accomplish.

PreTech

#5

How were you trying to coerce them, “delete alias checkinName” or “delete (checkinName as alias)”? Have you tried just “delete checkinName”?

#6

Try putting

set theCheckinFile to (a reference to file checkinName)

inside your tell block. The ‘reference’ used by AppleScript’s main dictionary is different then the ‘reference’ used by Finder’s dictionary. I just ran into a similar issue. Check out AppleScript: The Definitive Guide, as it does a pretty decent job explaining the difference.

Ian

#7

Hey… we feel your pain. The loose typing is a double-edged sword – it saves you a lot of work doing mundane tasks like changing numbers to strings, etc. but it can make problems like yours really confusing.

Ian’s answer is right on the money. And the book he recommends really is a big help. Like he says, two variables can have the same exact class name and have values that look exactly the same if you look at them, but if one’s created in the context of AS and the other in the context of an application (even finder.app), those two variables or references can be two completely different things. (Doh!)

There’s always a way. If you get really confused, sometimes I find it helps to back-track to string and re-coerce from there.


set pathstr to "Macintosh HD:Users:digger:Desktop:scripts.txt"

set theCheckinFileRef to (a reference to file pathstr)

tell application "Finder"
	
        -- Won't work...
	try
		delete file theCheckinFileRef 
	on error e
		log e -- can't make data into expected type
	end try
	
	-- just telling it to delete the path (supplied as a string) works!
	delete pathstr
	
	--This will work too, because the ref is created in the context of "tell Finder"...
	set theCheckinFile2 to (a reference to file pathstr)
	delete theCheckinFile2
	
end tell
#8

I assume that the variable ‘checkinName’ is actually a path, ktappe.

I’m also guessing that you used the term “a reference to” because, if you’d simply tried , you’ll probably have ended up with a runtime error number -1700 (errAECoercionFail), saying something like “Can’t make file "X:Y:Z" into type reference.”

However, the statement , used outside an application tell block, would return <file “X:Y:Z” of «script»> - something Finder wouldn’t understand, because it’s not a Finder reference. (Reading the file has no bearing on the problem.) In fact, while the error you’re now seeing might seem to be a new one, the problem hasn’t changed. The error is still number -1700 (although Finder’s error string is somewhat more cryptic than the original).

So, while “a reference to” has some valuable uses, ducking an error isn’t one of them. All it really does here is to defer evaluation - so that the error comes back and bites you later in the script (thus making debugging even more difficult).

If you really want a file specification, then you might like to try using .

However, I’d just skip the general coercion altogether - and simply jump straight to:

set destItem to first paragraph of (read checkinName)
tell application "Finder" to delete file checkinName

Sometimes, less is more… :wink:
#9

That was a super helpful explanation, kai. Thanks.