Thanks for responding so quickly to my question. I agree that the
"as list" in my third example is unnecessary, but my whole point is
that what should be an innocuous change is instead causing an error.
And I think you can agree that
task 1 of document 1 as task
item 1 of every task of document 1 as task
item 1 of (every task of document 1 as list) as task
should all be returning the same final result.
What event is your application getting for the third example?
Based on the parentheses I would expect it gets a request for all
tasks as a list. An application must always return a list, even if
it is empty, when it gets a request for 'every <something>. Only
when there is a whose clause would you ever return an error if the
result list is empty.
In the third example, my application is getting two events instead of
one. First, Applescript evaluates the expression inside the parens as:
Can't make <class Task> id "1797703789526674182" of document id 1 of
application "Life Balance" into type <class Task>."
Note that the 'as list' is superfluous since a request for every
item always returns a list. Doesn't hurt anything, just doesn't do
anything either.
Yes, that's what I thought, but that's not the way it's behaving.
The "as list" causes the overall expression to be broken up into two
separate core/getd events, and Applescript reports an error after
evaluating the second event. I can generate the same error by
breaking the expression up into two statements:
tell application "Life Balance"
set theTasks to every task of document 1
item 1 of theTasks as task
end
Note that this fourth example doesn't have any explicit "as list"
coercion, yet the second statement gets the same error as my third
example.
The way the script is written, the keyAppHandledCoercion parameter
applies to the portion inside the parentheses, which means
AppleScript is properly trying to perform a coercion to a task.
Well, in the third script there are actually _two_ coercions taking
place. I'm only returning keyAppHandledCoercion for the second
(task) coercion, since list is a builtin type.
Since I'm returning the same result in all cases, it sure looks to me
like Applescript is ignoring the keyAppHandledCoercion parameter in
the third and fourth examples.
--Stuart
On Sep 1, 2006, at 7:30 AM, Stuart A. Malone wrote:
I've been tracking down an error that occurs when scripting my
app. At first I assumed that it was a bug in my homegrown Carbon-
based Apple Event handling code, but now I'm starting to think it
might be a bug in Applescript...
Recently, I added code to set the keyAppHandledCoercion parameter
in the reply to typeBoolean true when the requested type matched
my class type. This was enough to make simple coercions like
these work correctly:
tell application "Life Balance"
task 1 of document 1 as task
end tell
tell application "Life Balance"
item 1 of every task of document 1 as task
end tell
However, when I try something more complex:
tell application "Life Balance"
item 1 of (every task of document 1 as list) as task
end tell
I get the error:
Can't make <class Task> id "1797703789526674182" of
document id 1 of application "Life Balance" into
type <class Task>."
The reason I think this might be a bug in AppleScript is that in
all three cases I'm returning exactly the same result from my core/
getd handler:
Is there a chance that Applescript is failing to notice that I've
set the keyAppHandledCoercion parameter in this third case?
Best wishes,
--Stuart A. Malone
Llamagraphics, Inc.
Makers of Life Balance personal coaching software
http://www.llamagraphics.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-implementors mailing list (Applescript-
email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/applescript-implementors/
email@hidden
