Closing a stack and deleting it too

[Mike Bonner]

Yep, as a library stack, IIRC the script being run is owned by the object
calling it.  If however you send the request directly to the library stack
(I think you can still do that) it may solve your issue.

On Fri, Oct 21, 2016 at 1:10 PM, Graham Samuel <livfoss at mac.com> wrote:

> Thanks, I will try to see if I am inadvertently doing what you say. The
> actual deletion code is in a library which is being used by the stack to be
> deleted (since it’s invoked by a menu item in the stack), although the
> library itself is in another mainstack. Interesting - I suppose while in
> use, a handler in the library ‘belongs’ to the stack which initiated its
> execution. Amazing how something apparently simple can become so
> complicated!
>
> Graham
>
> > On 21 Oct 2016, at 20:56, Mike Bonner <bonnmike at gmail.com> wrote:
> >
> > Make sure if you are doing a send to delete the stack that you don't have
> > it send to itself.  An external (hidden?) mainstack would be the way to
> go,
> > otherwise telling the stack to send the delete request to itself would
> be a
> > circular type of thing.  Can't delete the stack running the script, so
> send
> > a script "delete this stack" to the stack being deleted, which then can't
> > be deleted because its still running the script to delete itself.
> >
> > On Fri, Oct 21, 2016 at 8:55 AM, Graham Samuel <livfoss at mac.com> wrote:
> >
> >> Yes, I’m already trying that. Maybe I did it in an incorrect way. I am
> >> trying to go over it very carefully for the nth time. I have certainly
> seen
> >> some oddness in 8.1.1 related to this among other things, but I haven’t
> got
> >> a recipe yet.
> >>
> >> Thanks for the reminder.
> >>
> >> Graham
> >>
> >>> On 21 Oct 2016, at 16:37, Bob Sneidar <bobsneidar at iotecdigital.com>
> >> wrote:
> >>>
> >>> I thought this was an ongoing thread that had been answered, but at the
> >> risk of repeating all of you, The trick would be to send "close this
> stack"
> >> in 0 seconds. I've not tried it, so I am not sure if it actually works,
> but
> >> that is the prescribed method.
> >>>
> >>> Bob S
> >>>
> >>>
> >>> On Oct 21, 2016, at 01:46 , Graham Samuel <livfoss at mac.com<mailto:
> livfos
> >> s at mac.com>> wrote:
> >>>
> >>> I seem to be getting unreliable results from ‘close stack’. I note that
> >> the dictionary says:
> >>>
> >>> If the handler that closes the stack is in the script of the stack (or
> >> in the script of an object in the stack) and the stack's destroyStack <>
> >> property <> is true, the stack window <> is closed immediately, but the
> >> stack is not removed from memory until after the handler  <>completes.
> >>>
> >>> I find that if I have a stack with a lot of substacks, on executing
> >> ‘close stack’, just the mainstack closes, despite the despite having
> ‘purge
> >> stack on close’ and ‘purge window on close’ set in the main and all the
> >> substacks.
> >>>
> >>> If this command worked as I imagined, it would not be necessary, or
> >> indeed appropriate, to follow it with a ‘delete stack’ command.
> >>>
> >>> I think this failure to work as expected must be to do with message
> >> still waiting to finish, as suggested by the Dictionary entry - it’s
> >> probably a ‘menuPick’ handler, which is the only bit of script actually
> >> executing in the stack-to-be-deleted - but in my case apparently it
> never
> >> finishes. Is there a way of purging the message queue so that the
> ‘close’
> >> command always does ‘delete’ as well?
> >>>
> >>> If only I understood what ‘Close and Remove from Memory’ in the IDE
> >> actually does. I’ve been trying to find out for ages.
> >>>
> >>> Graham
> >>>
> >>> _______________________________________________
> >>> use-livecode mailing list
> >>> use-livecode at lists.runrev.com
> >>> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>