Libraries, 'start using' and stacks
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. )
More information about the Use-livecode