Re: Property Parent : load script (Changing File)???
Re: Property Parent : load script (Changing File)???
- Subject: Re: Property Parent : load script (Changing File)???
- From: has <email@hidden>
- Date: Wed, 16 Jan 2002 12:13:14 +0000
Jason Bourque wrote:
>
What I would like to happen when I compile a Property Parent is the
>
following.
>
>
At compiling the property it finds the newest version of a script that
>
begins with "HandlerLib " in a specified folder ((path to startup disk as
>
text) & "Script Handlers:").
>
>
>
This script itself is a loadable script. A Library of sorts.
>
>
So the script will never run, just contain sub routines.
>
>
So this eliminates the set the value at run time possibility.
>
>
>
I thought of using a run script.
Not necessary. Try this:
on loadParent()
--your code to find and return the sub-library here
end loadParent
property parent : loadParent()
I use this sort of thing quite a bit to make properties self-initialise
their values at compile time.
As far as loading at run-time goes (something I much prefer doing for
libraries, as it avoids the need to recompile everything each time you
change a single component), there's a number of methods you could use:
1. You can daisy-chain libraries together and then use a handler call that
propagates down that chain, loading a fresh copy of each library into its
respective property as it goes. You just load the topmost library into your
script, then send it the 'initialise' message.
2. A similar approach to 1. is to pass a record of libraries down through
the call itself, letting the recipients grab the bits they need.
3. Alternatively, you can load all the libraries into a set of properties
within a single script and let them access each other from there. In that
situation, you need to add global declarations to the top of each library
before they can see one another.
4. Probably the most exotic approach of all is to wrap your library code in
a constructor function. This is a great approach if you want to use the
parent property to inherit from another script at runtime. Just load the
script and call the constructor function to get a freshly-baked library out
at the other end.
How you'd do it would depend on your architecture. Also, if using a
chain-loading method, make sure you avoid creating any closed loops in the
chain (e.g. A loads B, B loads C, C loads A).
My Big Project of the moment uses all of methods 1 thru 3 (and other
projects have used 4), so I know these techniques are all quite usable.
Also, I can't get over how much easier my code's gotten to maintain through
using multiple small files instead of a single big one - regardless of how
modular the code is otherwise. If anything, I think the multi-file approach
helps you design good modular code right from the go (makes it harder to
throw together messy hacks than write good code to begin with - focusses
the mind, y'know - and it pays off in the end).
I'm afraid the above's just a quick summary of techniques, unfortunately -
I'm busy on other stuff right at this moment, so further details and
working examples might need to wait a bit if the above's not enough to get
you rolling. (Hmmm... y'know, sometimes I get these funny notions that I
should just go write up a book about this stuff. Maybe that should be The
Next Big Project - though d'you think anyone'd buy it?:)
HTH
has