Re: Why these errors?
Re: Why these errors?
- Subject: Re: Why these errors?
- From: Axel Luttgens <email@hidden>
- Date: Sat, 08 Feb 2014 14:15:44 +0100
Le 8 févr. 2014 à 02:56, Christian Boyce a écrit :
> [...]
> I have a second question. If the display dialog line doesn't have the "as string" at the end, I get this error:
>
> error "Finder got an error: Can’t make name of document file \"IMG_4420.jpg\" of folder \"Desktop\" of folder \"cboyce\" of folder \"Users\" of startup disk into type string." number -1700 from name of document file "IMG_4420.jpg" of folder "Desktop" of folder "cboyce" of folder "Users" of startup disk to string
>
> It seems funny that the error says "Finder got an error: Can't make name of document file… to string" when I can turn the name of the document into a string just by putting "as string" at the end. If I can do it that way, why can't the Finder do it? Or is something else doing the work-- that is, not the Finder? But still-- why not?
Hello Christian,
I tend to believe several things are at play here. One of these is the mechanism of implicit coercions, that may be implemented more or less extensively depending on the invoked command or the invoking context.
So, display dialog expects a text for its direct parameter.
Let's simplify your example and run this one in the ASE:
on dialogTest(smthng)
try
display dialog smthng giving up after 1
end try
end dialogTest
tell application "Finder" to set some_file to item 1 of desktop
dialogTest(1)
dialogTest({1})
dialogTest({1, 2})
dialogTest(some_file)
The log shows:
tell application "Finder"
get item 1 of desktop
--> startup disk
end tell
tell application "AppleScript Editor"
display dialog 1 giving up after 1
--> {button returned:"", gave up:true}
display dialog {1} giving up after 1
--> {button returned:"", gave up:true}
display dialog {1, 2} giving up after 1
--> error number -1700 from {1, 2} to string
end tell
tell application "Finder"
display dialog startup disk giving up after 1
--> error number -1700 from startup disk to string
end tell
It thus seems that the "display dialog" command implements some simple coercions, such as integer -> text and single-item list -> text.
But it will give up for anything more "complicated", especially for another application's object.
Since the error message is always the same, it could be inferred that it is "display dialog" who just says "sorry, I don't know what to do with the parameter's value"; without even trying to invoke the Finder's coercion capabilities in the last case.
Put in other words, I would be tempted to say that the "Finder got an error: ..." error string is somewhat misleading.
BTW, one may read in MacErrors.h:
errAECoercionFail = -1700, /* bad parameter data or unable to coerce the data supplied */
By contrast, let's consider another implicit coercion, implemented by AppleScript itself: if the first operand of operator "&" is of some class, the second operand will be coerced to that class (whenever possible, of course).
tell application "Finder" to set some_file to item 1 of desktop
log "" & 1
log "" & {1}
log "" & {1, 2}
log "" & some_file
In the log:
tell application "Finder"
get item 1 of desktop
--> startup disk
end tell
(*1*)
(*1*)
(*12*)
tell application "Finder"
get startup disk
--> "Boot:"
end tell
(*Boot:*)
Here, the Finder itself is asked to perform an item -> text coercion, and its implementation provides such a mechanism.
Consistently, the same overall behavior is obtained by making use of explicit coercions:
tell application "Finder" to set some_file to item 1 of desktop
log 1 as text
log {1} as text
log {1, 2} as text
log some_file as text
> The name of the file is already class "text" which I verified by changing the handler to look like this:
>
> on convert_the_file(some_file)
> set x to the name of some_file
> log class of x
> display dialog (x)
> end convert_the_file
>
> In this case the script runs fine, and the log shows "(*text*)" for the class of x.
>
> Why do I have to coerce "name of some_file" to a string if it's inside the display dialog line, but I don't have to do that if I get the "name of some_file" and pass it to the display dialog command?
Because, in that precise case, the Finder is asked for the file's name and, as a result, the "display dialog" command receives an AppleScript string, which is exactly what it expects; you may have a look at the log output of:
on dialogTest(smthng)
try
display dialog smthng giving up after 1
end try
end dialogTest
tell application "Finder" to set some_file to item 1 of desktop
dialogTest(name of some_file)
By contrast, the negative case you are considering is:
on dialogTest(smthng)
try
display dialog name of smthng giving up after 1
end try
end dialogTest
tell application "Finder" to set some_file to item 1 of desktop
dialogTest(some_file)
and chokes, as discussed above, with command "display dialog" asked to handle an application's object.
As a final note, having "name of some_file" working consistently outside of a tell block is a bit fortunate: keyword "name" exists in such a context and has the same underlying code 'pnam' as keyword "name" from the Finder's dictionary...
This may be contrasted with the error raised by some code like:
tell front window of application "Safari" to set some_tab to current tab
URL of some_tab
HTH,
Axel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden