Closing a stack and deleting it too

Graham Samuel livfoss at mac.com
Fri Oct 21 15:10:59 EDT 2016


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





More information about the use-livecode mailing list