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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
