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: Sat, 24 Jan 2004 01:20:55 +0100
Michael Terry wrote:
On Jan 22, 2004, at 10:55 AM, Wallace, William wrote:
[...]
Do these loaded scripts have parent property declarations in them
somewhere? I don't see them here, but you refer to the calling script
as if you had. I assume you must have, else your main script should be
getting lots of errors. Unless otherwise specified, the parent script
of a loaded script is <<script AppleScript>>.
Well... If I save this as a script:
-- Script1
on doThis()
return my name
end
and run this from within Script Editor:
set S to load script alias "path:to:Script1"
S's doThis()
the result I get is:
"Script Editor"
(really a nice thing to now have a scriptable SE now, with lots of
properties and commands ;-) )
In fact, a script's default parent is the default target application
(this is what the ASLG tells).
But you are right at saying that AppleScript itself is somewhere in the
way, as it makes some properties available.
Anyway, I don't know if there's a better explanation than that it just
doesn't work. Children are bound to their parents statically; they can
only see globals that were already initialized by the parent at
binding time. This means properties obviously--which are set at
compile time or when a script is created through a constructor
function--and any globals that have already had their values set when
the script became another script's parent.
For instance:
script a
global x
on init()
set x to 1
me
end init
end script
script b
property parent : a
parent's init()
parent's x
end script
run script b
--> error
Ouch! I needed some time to see what was your goal through that example!
Unless I'm wrong, the idea is to evaluate script "b" so that it returns
integer 1, that value being then passed to command "run script" which
should first implicitely coerce the passed value to a string; and the
evaluation of "b" must involve a communication between scripts "a" and
"b" through a global.
OK. There must be a way to do it. Have you ever seen AppleScript not
being to meet a challenge? ;-)
But first a preliminary note: I guess the "me' statement occuring within
init() was just typo, so that I will ignore it in the following.
The same way,
That given, very few things need to be changed in your proposal:
script a
on init()
-- Avoid to provide identifier x with
-- unneeded visibility; so let's put
-- this one here.
global x
set x to 1
end init
end script
script b
property parent : a
-- For legibility and maintenance ease,
-- let's introduce an explicit run handler.
on run
-- Anyway, globals are not inherited, nor
-- does identifier x appear in the code in a
-- way to avoid it to be made local. So,
-- this one is needed to make x's scope
-- explicit.
global x
parent's init()
x
end run
end script
run script b
--> 1
But then, does script "b" really need to be a child of script "a"?
After all, globals being outside of inheritance matters, and since "a"
is anyway hard-coded within script "b"'s definition, this one works as well:
script a
on init()
global x
set x to 1
end init
end script
script b
on run
global x
a's init()
x
end run
end script
run script b
--> 1
Now, one could also use the trick of using "my x", which relies on
AppleScript's infamous tendency to fetch defined globals whenever a
property (own or inherited) can't be found; but this always is a very
bad idea, not only because it is misleading ("my" is associated to the
notion of property), but also because it make scope-clashes even more
probable.
Anyway, that could look like this:
script a
on init()
global x
set x to 1
end init
end script
script b
on run
a's init()
-- Horrible... To see why, just have a look
-- at a's definition.
my x
end run
end script
run script b
--> 1
Even though we tried to initialize x by calling init(),it doesn't
matter because the globals visible to script b were set when script a
was compiled in as b's parent.
Not sure to understand what you mean.
Unless I'm wrong, "property" statements are evaluated before a script's
execution.
But globals are a matter of scoping and of "on the fly" execution.
Now, instead we do this:
script a
global x
on init()
set x to 1
me
end init
end script
script b
property parent : a's init()
parent's x
end script
run script b
--> 1
That's a nice one; I would never have thought of it... ;-)
As properties are evaluated before script's execution, so is script a,
and thus it's code that tends to provide x with an exessive visibility.
So, you may simplify the whole matter as:
script a
on init()
global x
set x to 1
me
end init
end script
script b
property parent : a's init()
end script
x
--> 1
Hmmm.
and everything is hunky dory. I don't know why children have this
somewhat standoffish relationship with their parents. Even unrelated
scripts can access calling scripts' globals
But just because globals are one matter, inheritance relationships
another one.
You don't need to have script objects (except of course the top-level
one that you can't avoid) to use the concept of globals; handlers suffice.
And if unrelated scripts may access globals, that's precisely what
globals are for: if really needed, they allow to have some data shared
througout the whole code.
with ease, if we amend your examples:
[...]
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.