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