Libraries, 'start using' and stacks

Dave Cragg dcragg at lacscentre.co.uk
Wed Oct 4 17:22:41 EDT 2006


On 4 Oct 2006, at 16:49, Graham Samuel wrote:
> .
> It seems to me that 'start using' can invoke a mainstack (rather  
> than just a substack of the calling app) and presumably the library  
> mainstack can have substacks although so far I don't know how their  
> scripts (or the scripts of any objects in the library system) fit  
> into the message path.

Only the script of the stack you "start using" gets put at the "back"  
of the message path. (I'm using "back" in the sense that messages  
travel backwards from button to card to stack to libraries. Some  
people use "up" and some people use "down". Very confusing.) The  
scripts of any substacks or objects in the stack don't get placed in  
the message path. But they do exist in the same way that objects and  
substacks in normal stacks exist. For example, you can "send" a  
message to card 1 of stack "myLibrary" if you want to.


> What I don't understand is whether the stack one 'starts using' is  
> actually opened at that point.

The stack doesn't have to be open before you "start using" it. You  
can "start using" a stack directly with a file reference. (start  
using stack "libsFolder/myLib.rev") When you start using a stack,  
it's open in the sense that it is loaded into memory. But it doesn't  
receive any openstack/opencard messages. Also, it isn't visible, but  
it can be made visible in the normal way. (show stack "myLibrary")

>
> How do people approach the problem of a library of stacks, which  
> might for example be visible to the user, and might contain  
> controls such as buttons?

The only kind of library stacks I've used which might be visible to  
the user are status panels, for example, to show the progress of url  
uploads and downloads. I don't really treat these any differently  
from script-only libraries. Generally, I keep libraries as substacks  
of my main application stack, but I have placed then externally as  
well, in a special "libraries" folder. The advanatge of keeping them  
external is that they can easily be moved or shared between projects.  
The disadvantage is that you have to update your library loading  
routine in your main application stack if you ever move or rename the  
libraries folder. (Or deal with phone calls when your user deletes  
the folder. )

Cheers
Dave





More information about the Use-livecode mailing list