Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
- Subject: Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
- From: Nigel Garvey <email@hidden>
- Date: Sun, 11 Apr 2004 16:17:25 +0100
Michael Terry wrote on Fri, 9 Apr 2004 18:15:26 -0700:
>
set x to 3
>
set y to 4
>
>
set a to a reference to x
>
set b to a reference to y
>
>
set contents of {a, b} to {"hello", "there"}
>
--> Can't set contents of {x, y} to {"hello", "there"}.
I suppose that setting variables by list is a convention that the
compiler understands and can produce code for. You can't actually set a
list to anything, but if you write:
set {contents of a, contents of b} to {"hello", "there"}
... the compiler understands that what you really want is to evaluate the
contents of a and set the result to "hello", evaluate the contents of b
and set the result to "world", and return the results in that order as a
list. If the contents of a and the contents of b both turn out to be
variables at run time, all will go well. But the compiler has no way of
knowing beforehand what the contents will be; it can only apply the
'contents of' code and trust that you know what you're doing.
In the case of:
set contents of {a, b} to {"hello", "there"}
... the compiler doesn't recognise this as a setting by list. It sees an
instruction to apply the 'contents of' code to {a, b} and to set the
result to {"hello", "there"}. At run time, the 'contents of' code returns
a *list* {3, 4}, which obviously can't be set to anything.
>
I don't know why that shouldn't work when you can get the contents of
>
each reference in a list of references, like so:
>
>
get contents of {a, b}
>
--> {3, 4}
It's possible to extend the references:
set p to ref a
set q to ref b
get contents of {p, q}
--> {x of <<script>>, y of <<script>>}
But it's still a list. Solid data - not a line in a script.
>
and you can set an lvalue through a reference, example 1:
>
>
set a's contents to 7
>
x
>
--> 7
>
>
and, example 2:
>
>
set q to a reference to name of first file of item f of application
>
"Finder"
>
set q's contents to "hello there"
>
--> "hello there"
In these cases, you're getting the contents of references, not of "solid"
data types. Also, the references both refer to things that *can* be set -
a variable and an application property.
>
But none of the foregoing even touches on the bigger problem, the
>
second drawback to the original code, which I repeat as a reminder:
>
>
tell application "Finder"
>
set {name of first file of folder 1 of f, name of first file of folder
>
2 of f} to {"something", "else"}
>
end tell
>
>
See, separate Apple events are required for each property you assign
>
to. You can see that in the event log that's recorded when you run it:
More basically, that's the format you have to adopt to make the compiler
understand that you want one file to be named "something" and the other
to be named "else".
>
tell application "Finder"
>
set name of first file of folders 1 thru 2 of f to {"hello", "there"}
>
end tell
>
>
That seems like the best way to do it to me. Is it dumb for some
>
reason? Would it be bad to extend 'set' this way? If so, is there a
>
suggested command name to do this sort of thing?
I'm guessing that it would be *possible* for an application to have this
ability, but your syntax would be very confusing. It's basically saying:
'set each name to the list {"hello", "there"}.' It might be better for an
app to implement some sort of 'distribute' command:
tell application "Finder"
distribute {"hello", "there"} to name of first file of folders 1 thru
2 of f
end
NG
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.