Should have said, yes it’s a mainstack. I am beginning to think that the issue
is that when I close the stack it is also purged from memory (as it says in the
Dictionary, with provisos that I think I have obeyed), so that the following
‘delete’ doesn’t have anything to delete - this should generate an error, but
I find that if I simply cut out the ‘delete stack’ line, then everything works
- this includes reloading a stack with the same name as the one closed, and no
name conflict occurs. OTOH the Project Browser in the IDE claims the stack is
still there, and an ‘exists’ enquiry returns true! Odd. The struggle now is to
reduce this to something small enough to report as a bug.
Not sure if anyone else is interested in this, but if so, thanks for listening!
> On 14 Oct 2016, at 11:30, Graham Samuel <livf...@mac.com> wrote:
> 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 preferences:
>> 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
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription