Re: loading a subroutine properly
Re: loading a subroutine properly
- Subject: Re: loading a subroutine properly
- From: email@hidden
- Date: Thu, 1 Feb 2001 23:22:18 EST
In a message dated 2/1/01 6:02:12 PM, Bill Planey wrote:
>
Simply because I wanted to modularize part of one of my scripts, I copied
>
and pasted a certain chunk of code into another compiled script. The
>
mother script makes calls to handlers and the daughter script makes calls
>
to some of the same handlers (in other words, some of my handlers are called
>
by both routine and sub-routine). I copied the variables from the mother
script
>
(those which identify the location of the handlers - the "set" statements
>
which spell their location out). I am sure there is some way to avoid this
>
redundancy, but that is not my main concern (unless it might be the cause
>
of my main problem).
>
>
My subroutine is basically:
>
>
on run
>
>
set handlers -- create variable and declare locations
>
tell application "Microsoft Word"
>
do stuff -- using handlers
>
end tell
>
>
end run
>
>
...and this subroutine is called in the mother script this way:
>
>
load script SubroutineFile -- where the location of SubroutineFile
>
-- has already been set earlier
>
>
this step occurs between chunks of code that call the exact same handler
>
used in the subroutine.
>
>
The actions that the subroutine is supposed to perform do not happen.
>
They are simply skipped.
>
>
What am I doing wrong?
I think your problem is that you think loading a script object will cause
that script object's run handler to execute; not so. Creating a script object
does nothing - you have to call the script object's handlers, including the
run handler if there is one, to cause anything to happen.
Forgive me, but I am totally confused by your use of "mother," "daughter",
"routine," "subroutine," "locations," and "handler." Let's make sure our
terms are in sync (anyone else chime in please).
subroutine - a slightly dated and less used term from the days when Pascal
ruled. "Handler" would be the more current term.
handler - an Applescript "subroutine" which performs a task in a modularized
way, which may or may not be passed values and which may or may not return a
result.
parent - a programming object which may have children and pass attributes on
to them. IMHO, Applescripts really can't be true parents. Much more
thoroughly implemented in languages like Java.
mother - the female human who bore you
Script object - compiled Applescript code which may be treated as a separate
entity. Sometimes incorrectly refered to as a child script.
location - a housing asset
routine - daily humdrum. More humdrum when using a PC.
child - a programming construct which can inherent characteristics from a
parent script. In Applescript, sometimes used as short for script object.
daughter - the female offspring of a mother (and father - and it takes a man
to be a dad)
Here's a convoluted example to understand script objects and handlers and how
they interact. In this example, john (and/or mary) could just as easily be
set by "set john to load script johnpath" where johnpath is the file path to
the compiled script.
Again, creating a script object does nothing - you have to call the script
object's handlers.
set x to john's addthree(7)
log x
--> 10
set x to mary's fiddle(6, me)
log x
--> 18
set x to john's fiddle(2, mary, me)
log x
--> 8
set x to john's addthree(mary's subtractfour(my fiddle(3)))
log x
--> 3
set x to john's usemary(7)
log x
--> 3 ? Nope. It errors because john doesn't know mary
script john
on addthree(x)
return x + 3
end addthree
on fiddle(x, otherScript, anotherScript)
set y to x * x
return otherScript's fiddle(y, anotherScript)
end fiddle
on usemary(x)
return mary's subtractfour(x)
end usemary
end script
script mary
on subtractfour(x)
return x - 4
end subtractfour
on fiddle(x, otherScript)
return otherScript's fiddle(x)
end fiddle
end script
on fiddle(x)
return x * x div 2
end fiddle
I hope that helps. Again, forgive me if I have totally missed your point.
Jeff Baumann
email@hidden
www.linkedresources.com
Comparing MHz between the G4 and Pentium is like comparing the popular vote
between Bush and Gore; it's interesting, but it isn't what matters.