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