Delete a stack from memory - fails?
lists at mangomultimedia.com
Tue Jul 29 13:47:25 CDT 2008
On Jul 29, 2008, at 2:25 PM, J. Landman Gay wrote:
> No, you're right, it closes and is removed. What I was thinking is
> that since pending messages prevent quitting, they also prevent
> closing -- but they don't. So scratch that. Like you, I've always
> found "delete stack" to be reliable.
The reason delete stack *appears* unreliable sometimes is because you
can code running in the IDE that refers to a stack by the full file
path rather than by the stack name in memory. This brings the stack
back into memory behind your back.
Plugin developers who create plugins that track objects in the IDE
don't have it easy though. If your plugin stores a reference to an
object using the short name of the stack (the name in memory) then you
have to update it if the developer changes the stack name or the
object reference is no longer valid. If the developer happens to have
messages locked at the time then the plugin will never be notified of
this stack name change.
If you store references to an object using the path to the stack file
then anytime you access the stack it is loaded back into memory, even
though the developer may have unloaded it which isn't good either.
So what is a plugin developer to do? If using the short name of the
stack in your object refs and the object no longer exists then you
have to determine if:
a) The object was deleted.
b) The stack name was changed (with msgs locked) but the object ref is
c) The stack name was changed (with msgs locked) and the object was
Very tricky. I think the IDE engine could use a mechanism whereby a
plugin could register for a message that was received regardless of
whether or not messages are locked.
Blue Mango Learning Systems
Developer Resources: http://revolution.bluemangolearning.com
More information about the use-livecode