Phil, thanks for the suggestion. I timed out last night and tried it this morning. Strangely it didn’t work - got the same error as before (347). So I’m still investigating. I am fairly sure that there is an obscure bug (or at the very least, a change of behaviour) in LC 8.1.x compared to earlier versions, but it is not straightforward. Onward!
Graham > On 13 Oct 2016, at 19:32, Phil Davis <rev...@pdslabs.net> wrote: > > Hi Graham, > > What happens if you do only this? > > lock messages -- assuming you don't want any handlers to be > triggered by the stack's closing > delete stack "myDataStack" > > I'm also assuming "myDataStack" is a mainStack and not a substack. (As you > know, you can't remove a substack from memory independent of its mainStack > unless you end its existence with "delete stack".) > > Food for thought... > > Phil Davis > > > > On 10/13/16 10:10 AM, Graham Samuel wrote: >> I have a situation where I want to close a stack and then delete it, so that >> it no longer exists in memory and so that no naming conflicts occur when I >> load a fresh stack with the same name. This used to work - part of a script >> running in a different stack to the one being deleted: >> >> set the cantDelete of stack "myDataStack" to false >> >> set the destroyStack of stack "myDataStack" to true >> >> set the destroyWindow of stack "myDataStack" to true >> >> close stack "myDataStack" -- this should ensure that there are no messages >> operating in that stack >> >> delete stack "myDataStack" -- this should remove it from memory >> What happens in 8.1.1 rc2 (on a Mac with El Capitan, if that’s relevant) >> is that all goes well until the ‘delete’ command, when I get error 347, >> which is “stack locked, or object’s script executing”. Well, since the stack >> is closed (this is apparent on the screen), its scripts can’t be running, >> and it’s not locked (whatever that means - the dictionary is not helpful), I >> don’t think the error is the correct one. >> >> The problem exists both in the IDE and in the standalone version of the >> program. >> >> I have two problems tracking this down: >> >> (a) it used to work up to LC7.x; and >> >> (b) an attempt to abstract the issue by repeating it with some very simple >> stacks doesn’t demonstrate the error. >> >> Can anyone suggest an approach to debugging this? I am totally foxed. >> >> TIA >> >> Graham >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > -- > Phil Davis > > _______________________________________________ > use-livecode mailing list > use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode