On Jul 30, 2008, at 9:52 AM, David Bovill wrote:
I guess - I have a lot of "plugins" that track objects and code. You
are
referring to using the "namechanged" message? I guess lockmessages
also
blocks front scripts
Correct. If you are working in a controlled environment you can ensure
2008/7/29 Trevor DeVore <[EMAIL PROTECTED]>
>
> 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
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
Trevor DeVore wrote:
On Jul 29, 2008, at 2:03 PM, Trevor DeVore wrote:
On Jul 29, 2008, at 1:44 PM, J. Landman Gay wrote:
Trevor DeVore wrote:
Polling is entirely possible. delete stack is very reliable. Like I
said, I've never had it fail. When it *appears* to fail it is
usually because s
On Jul 29, 2008, at 2:03 PM, Trevor DeVore wrote:
On Jul 29, 2008, at 1:44 PM, J. Landman Gay wrote:
Trevor DeVore wrote:
Polling is entirely possible. delete stack is very reliable. Like
I said, I've never had it fail. When it *appears* to fail it is
usually because something is going on
On Jul 29, 2008, at 1:44 PM, J. Landman Gay wrote:
Trevor DeVore wrote:
Polling is entirely possible. delete stack is very reliable. Like I
said, I've never had it fail. When it *appears* to fail it is
usually because something is going on in the background that brings
the stack right bac
Trevor DeVore wrote:
Polling is entirely possible. delete stack is very reliable. Like I
said, I've never had it fail. When it *appears* to fail it is usually
because something is going on in the background that brings the stack
right back into memory.
If the stack has any pending messages r
On Jul 29, 2008, at 11:05 AM, David Bovill wrote:
2008/7/29 Trevor DeVore <[EMAIL PROTECTED]>
Every time the engine checks for the existence of a stack, accesses a
property or issues the go command using the filename of a stack the
stack is
loaded into memory. In your Galaxy example what is
2008/7/29 Trevor DeVore <[EMAIL PROTECTED]>
> On Jul 29, 2008, at 6:46 AM, David Bovill wrote:
>
> Every time the engine checks for the existence of a stack, accesses a
> property or issues the go command using the filename of a stack the stack is
> loaded into memory. In your Galaxy example what
On Jul 29, 2008, at 6:46 AM, David Bovill wrote:
closes and removes a stack from memory (for a mainstack not substack)
regardless of the destroystack/window status or whether the stack is
used as
a library. The issue is that it does not always work - and I could
not track
down why. Thought I
Thanks Andre - but destroystack is not the issue. For instance:
delete stack "test"
closes and removes a stack from memory (for a mainstack not substack)
regardless of the destroystack/window status or whether the stack is used as
a library. The issue is that it does not always work - and I coul
David,
you must set the destroyStack property to true if you want it to be
removed from memory I think. Like:
set the destroystack of stack "Test" to true
close stack "test"
Andre
On Mon, Jul 28, 2008 at 5:37 PM, David Bovill <[EMAIL PROTECTED]> wrote:
> What is a reliable way to delete a stack
What is a reliable way to delete a stack from memory?
delete stack "test"
can fail. I have a stack that was a library stack, contians no back or front
scripts, that uses no externals but I cannot delete from memory.
I am wandering if it could be due to having used shell commands that somehow
ha
13 matches
Mail list logo
