Office of Digital Humanities
As a programmer you will often find yourself solving similar problems in many different stacks. That means you may often want to reuse code in different projects. Now, you could just copy and paste message and function handlers from one stack to another, but something tells you that would be a bad idea. Why? Let's say you come up with a great new function for proportionally resizing objects that you begin incorporating into all of your stacks. Months later, you discover an way to make your function better and faster. What to do?
If you had ignored your hunch and copied your function into all of your stacks, you would have to go back and manually modify each stack in which you use this function. On the other hand, if you had wisely looked for a way to efficiently reuse your code, you could have written it just once and saved it in a library stack that you incorporated into all of your projects. A library stack is really just a normal stack, but instead of having lots of different cards with buttons and fields and such, it simply has frequently-used handlers in its stack script. This stack is then associated with every project in which you want to have access to the common handlers it contains.
Making a stack into a library is easy with one of the following synonymous commands:
start using stack "myLibrary.livecode" --or-- library stack "myLibrary.livecode"
This places the handlers in the library's stack script into the message path after the current stack. (See illustration at right.) When calling a library stack, remember that all of the standard rules for referring to a file outside of the current stackfile apply; thus, myLibrary.livecode would have to be in the defaultFolder, or you would have to provide an absolute file path to its location on the drive.
start using stack (specialFolderPath("resources") & "/myLibrary.livecode")
--or--
library stack (specialFolderPath("engine") & "/myLibrary.livecode")
Another strategy for keeping track of your library stacks is to make a library stack a substack of your mainstack so that it could be found without having to worry about file paths.
Typically you would place these commands in the openStack handler of the stack in which you want to have access to the scripts in the library. When you exit that stack, or if you just don't need access to the library anymore you can remove it by using:
stop using stack "myLibrary" --or-- release library "myLibrary"
Notice that in this case you only have to refer to the library stack's name, not the file path to the stackfile. That's because it is now open and known to your stack.
Library stacks can hold more than just scripts. Let’s say you have some common images that you like to use for button icons in lots of stacks. Just include these images in your library stack, start using the library stack, and your icon library becomes available to any stack that is using the library.
properties
You can find out which stacks are currently in use as libraries by using the stacksInUse property or its synonym the libraries. This will list all of the stacks being used as libraries by their stack names, one stack per line.
put the stacksInUse put the libraries --> Would produce a list like this: general_lib functionsLibrary myAwesomeLibraryStack
You could use it like this, for example:
if "general_lib" is among the lines of the libraries then
release library "general_lib"
end if
--or--
if "general_lib" is not among the lines of the libraries then
library "general_lib.livecode"
end if
messages
libraryStack - Sent to a stack when the stack is placed into the message path with the start using command
on libraryStack answer "The expanded command set library is now available." end libraryStack
releaseStack - Sent to a stack when the stack is removed from the message path with the stop using command.
on releaseStack answer "The expanded command set library is no longer available." end releaseStack