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!
> 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
>> 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.
>> use-livecode mailing list
>> Please visit this url to subscribe, unsubscribe and manage your subscription
> Phil Davis
> use-livecode mailing list
> Please visit this url to subscribe, unsubscribe and manage your subscription
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription