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

[Dar Scott]

On Thursday, February 5, 2004, at 04:14 PM, J. Landman Gay 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.

This makes it a lot easier for the library developer, too.

It does put a lot more work on the application developer.  The app 
developer needs to made sure that needed libraries are started and are 
started before all needs.

Assuming externals get resolved in this and this seems to be a common 
practice, I'm happy with this.

Maybe library makers could keep information in properties that can help 
if people want to use it.

>
>> 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.

Do you start using everything in the folder or do you use a list?  Do 
you generate the list by hand?

> 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.

Won't this run into the ten backscript limit?
Suppose a library supplier wants to encrypt the library?
What's a good way to insert these?  Explicitly at preOpenStack?
I guess this would not apply to libraries needing menu or dialog 
substacks.

Dar Scott