Where goes stacks, included stacks and externals? (was Dialogs inlibrary organization)

J. Landman Gay jacque at hyperactivesw.com
Thu Feb 5 18:14:21 EST 2004


On 2/5/04 4:57 PM, Dar Scott wrote:

> But what if it is not in the expected location?
> 
> Library A' from vender A needs library B' from vender B.  Library A' has 
> some notion where B' is and refers to it there.  Developer C puts B' in 
> a different location and then makes the developer's app C' start using 
> B' and then A'.  Should C expect this to work?

My opinion: Library authors should not expect their stacks to be in any 
particular location. That should be the stack developer's job. The 
library author should simply annotate any dependencies, and let the 
stack author know that dependent stacks must be put in use.

> In general, the track goes like this:  What are common styles of stack 
> organization that might be considered good practice?  What might a 
> library supplier do as good practice to make a library easy to use in 
> styles of stack organization?

I don't think there is an official established procedure, but I'd put 
all my library stacks together in one folder. When it was loading time, 
I'd set the directory to that folder and start using them.

There is another, perhaps more efficient, way to use libraries though, 
and it is the way used by Revolution itself. Store the libraries as 
button scripts somewhere (in a substack, or a card you never go to, or 
even just invisible on a card somewhere) and insert the scripts into the 
back as necessary. That way you don't need any external stacks at all 
and you get your monolithic build besides. This is the method I tend to 
use. Having lots of external stacks can become hard to manage, and it is 
easy to just pop a script into a button if I know my app will need to 
use it. Another advantage of this method is that you don't need to worry 
about file paths at all.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com


More information about the use-livecode mailing list