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