Re: Error Number: -10006 H-E-L-L-L-P!
Re: Error Number: -10006 H-E-L-L-L-P!
- Subject: Re: Error Number: -10006 H-E-L-L-L-P!
- From: Axel Luttgens <email@hidden>
- Date: Fri, 23 Jan 2004 10:18:33 +0100
Wallace, William wrote:
[...]
What I don't understand is why script1 throws a -10006 error
(errAEWriteDenied)
Thanks, Emmanuel! ;-)
when trying to set the value of w to item 1 of y. The dialog boxes at
the end of the main script show that the value of z has been changed
to 4, the value of x has been changed to "howyadoin", but w is, of
course, undefined because of the error -10006. Why can't script1 set
the value of w? Furthermore, If I change the main script to initialize
the value of w to "today" for instance, it all works. Why?
This simplified version will show the same problematic behavior as your
original code did:
--main script
property z : 3
global w, x, y
set m to load script alias "path:to:script1"
set x to "hi"
set y to {"yesterday"}
m's doIt()
display dialog z --> 4
display dialog x --> "howyadoin"
display dialog w --> (we don't arrive here...)
--loaded script1
to doIt()
set my parent's z to 4
set my parent's x to "howyadoin"
set my parent's w to (item 1 of my parent's y) --> error
end doIt
And let's compare above code to the following one:
--main script
property z : 3
set m to load script alias "path:to:script1"
set x to "hi"
set y to {"yesterday"}
m's doIt()
display dialog z --> 4
display dialog x --> howyadoin
display dialog w --> yesterday
--loaded script1
to doIt()
global x, w
set my z to 4
set x to "howyadoin"
set w to (item 1 of my parent's y)
end doIt
Some comments (quick ones, as my previous two-parts message has been
long enough, hasn't it?):
1. Statement "global w, x, y" has disappeared from main script.
As we are on the top-level of the script (TLS), any variable identifier
V appearing at that level an not preceded by a "property V: ..."
statement in the code will implicitely refer to a global variable.
In that sense, a "global V" statement is not really required the TLS,
and may even be harmful by increasing the visibility of identifier V.
Note that the main script defines/initializes one property (z),
defines/initializes 3 globals through "set ... to ..." (m, x, y) and
also refers to one global to be defined/initialized somewhere else (w).
2. The "my parent's" reference applied to x and w have disppeared from
script1.
You clearly wanted x and w to be defined as global variables.
So, let's them defined as such for handler doIt through a "global x, w"
statement.
3. The "my parent's z" has been replaced by "my z" in script1.
Unless you really want to refer to the parent's property (skipping an
eventual property z defined in script1), let inheritance just work.
After all, that is why it is for, isn't it? ;-)
Note that the "my" keyword is still needed; without it, and because
identifier z doesn't appear anywhere else within script1, identifier z
would be taken a a local one to doIt().
As a result, doIt() will now define/initialize a global variable z.
As a side-effect, the programmer's intents appear more clearly, and the
whole thing should thus be more easily manageable.
So, what happened with your original code (as of its simplified version)?
Just before the execution of script1' doIt(), the state is as follows:
a parent property z exists and is bound to value 3
a global variable x exists and is bound to value "hi"
a global variable y exists and is bound to value {"yesterday"}
there is an entry w in the global name space
When doIt() then executes:
set my parent's z to 4
the property z is found and just bound to its new value 4.
Then comes the execution of:
set my parent's x to "howyadoin"
This will lauch a search for a property x.
There is none, but something named "x" at the TLS can be found; just use
that one and bind it to new value "howyadoin".
Finally:
set my parent's w to (item 1 of my parent's y)
Here, nothing really usable, just a name w in the gloabl name space.
Something has thus to be created. Given the reference form "my parent's
w", this should be a new property for the parent script. But script
objects can't be modified; only the values of their properties may. Bang.
On the other hand, when you tried by initializing w from the main
script, you were then in the same case as for the execution of "set my
parent's x to "howyadoin"".
At this point, you might be saying to yourself "well, if you can get
it to work, then problem solved..." That isn't good enough! I want to
know why it works one way but not the other, [...]
I can only agree with you. :-)
[...]
You're welcome!
I'm just hoping not being more confusing than anything else...
Axel
_______________________________________________
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.