Referencing a stack that is not open
SimPLsol at aol.com
SimPLsol at aol.com
Sat Jul 14 12:48:46 EDT 2007
Dan,
David provided a very good, and very concise, explanation.
I'd only add two things:
1. If you go invisible to a stack, that stack will remain invisible when it
is closed. So the next time you go to it, it is invisible - but open. Drove me
crazy until I realized what was happening.
2. It is critical to "delete" (badly named, indeed) any stack loaded into
memory by opening or referencing - if other users can access it. For instance,
say you have a data stack that is shared by several users on a network. User A
opens it and it loads into RAM, User B opens it, makes some changes and then
closes it (yes, it is possible for A and B to both be writing to the same open
file - at least in OS X, this was impossible in OS 9). Now A closes the stack -
and overwrites B's changes. This problem seems to be magnified if the data is
stored on a NAS.
Here is an abbreviated sample of the way we do it:
on getSomeData pTheSourceStack
set lockMessages to true
go invisible to pTheSourceStack
get field "Some Important Field" of stack pTheSourceStack
delete stack pTheSourceStack
end getSomeData
The reason for the "set lockMessages to true" is the stacks we open in this
way have a preOpenStack script that makes them visible (in case we want to open
them directly, instead of remotely). Without the "lockMessages" they would be
come visible, then invisible when the next line executes "go invisible to
pTheSourceStack".
You can also open the source stack, quickly transfer the required info to
variables, then immediately delete the source stack.
Paul Looney
**************************************
Get a sneak peak of the
all-new AOL at http://discover.aol.com/memed/aolcom30tour
More information about the use-livecode
mailing list