Delete a stack from memory - fails?

[Trevor DeVore]

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  
otherwise valid.
c) The stack name was changed (with msgs locked) and the object was  
deleted.

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.

-- 
Trevor DeVore
Blue Mango Learning Systems
ScreenSteps: http://www.screensteps.com
Developer Resources: http://revolution.bluemangolearning.com