Thanks Mike - I should have made clear in my description that the ‘close’ and ‘delete’ actions are being run from another mainstack whose stack script is being used as a library by the stack I’m trying to delete. The idea is forming in my mind as I write that since the menu that invokes the library is in the stack I’m trying to delete, this might cause trouble since technically the menu's script is still executing when the library’s ‘close’ and potentially ‘delete' scripts are invoked… hmm. Maybe I should try some kind of ‘send’ structure that makes the menu action close before the delete, or maybe (groan) I should move the menu to the permanent (splash) stack that contains the library.
Thanks for making me think some more! Graham > On 19 Oct 2016, at 17:57, Mike Bonner <bonnm...@gmail.com> wrote: > > Accidental send. *sigh* I think the point is.. If the substack is running > the script that deletes the mainstack, since the 2 are inextricably linked, > the delete fails. If you change your substacks to all be mainstacks in > their own right, it should and does work. > > On Wed, Oct 19, 2016 at 9:55 AM, Mike Bonner <bonnm...@gmail.com> wrote: > >> Silly question but.. If the mainstack has a bunch of substacks, and you >> try to close and remove the mainstack from memory while the substacks >> remain open, is this even possible? Substacks have a mainstack property, >> and it seems the message path is kinda hardwired in that instance. If you >> do manage to close and delete the mainstack all its substacks should go >> away too (but the error appears instead) >> >> I tried an experiment.. I made a mainstack and a substack. Just because, >> I turned the substack into a palette. trying to delete the mainstack while >> its still open gives me the error you refer to. Closing the mainstack of >> course works fine. (and yes, the cantdelete of the mainstack is set to >> false) Then deleting the mainstack after its closed (from the message box) >> effectively kills the mainstack, AND the substack and (in version 9) pops >> up an empty error dialog. >> Placing a button on the substack that attempts the deletion of the >> mainstack (first closing, then deleting) fails and causes the error you >> note. >> >> You said it works with a stack with 1 palette substack.. The palette >> substack.. does it actually have the mainstack set AS its mainstack? >> >> On Wed, Oct 19, 2016 at 9:37 AM, Graham Samuel <livf...@mac.com> wrote: >> >>> I am still going on about how to reliably execute ‘close stack and delete >>> from memory’ via script. I’m using LC8.1.1 rc2 on a Mac. The latest pickle >>> I’ve got into is this: >>> >>> I have a stack “myMainStack”, which has quite a few substacks - they’re >>> palettes which user can open to access tools etc. All of them have their >>> ‘cantDelete’ property set to false. I have a menu which includes an item >>> for resetting the program, which involves deleting the stack “myMainStack” >>> both in RAM and on disk, and then reloading it from a file in the program’s >>> resources folder. In the IDE, I invoke this menu item and step through >>> until it executes: >>> >>> close stack “myMainStack” >>> >>> Then the actual mainstack’s window closes. Those palettes which were open >>> stay open. I have a feeling that the whole thing should close (this is an >>> option I chose for the mainstack - ‘purge stack on close’, ‘purge window on >>> close'), but never mind, that’s what happens. >>> >>> If I then execute >>> >>> delete stack “myMainStack” >>> >>> from the message box, I get >>> >>>> Message execution error: >>>> >>>> Error description: Object: stack locked, or object's script is executing >>>> >>>> Hint: button "File" of group “mytMenu" of card “MainDisplay" of stack >>> "/Users/Graham/Library/Application Support/PointPlots/myMainStack >>> .livecode" >>>> >>>> >>> As the stack is closed, it can’t be executing scripts: it’s not locked in >>> that its ‘cantDelete’ property is set to false. Furthermore the file >>> mentioned in the error message isn’t there, because my program deliberately >>> deleted it earlier in the script. So this error makes no sense, but why >>> should it be an error at all? The engine ought to be pointing at the stack >>> in RAM, not on disk - the Project Browser says it’s there still. >>> >>> Trying to test this with a simple mainstack with one palette substack >>> does not exhibit the problem. >>> >>> This apparently simple requirement is driving me crazy. >>> >>> TIA for any help. >>> >>> 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 >> >> >> > _______________________________________________ > 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