How to ensure that 'close stack' destroys the stack in RAM?

[Bob Sneidar]

Perhaps the rule of thumb is never use two stacks with the same name in the same project. You may want to give the template stack a different name, then store the name of whichever stack you want to work with in a variable, then update all references to that stack to use the variable. 

Bob S


> On Oct 17, 2016, at 07:07 , Graham Samuel <livfoss at mac.com> wrote:
> 
> Thanks Mark for that intervention. In the way this is a gotcha that should be better documented, since one **must** populate the stackFiles property as a side effect of including the stacks in the project in its standalone settings - the information in the list of stacks to be included is exactly the contents of the stackFiles property, at least initially. If say this contains (as mine does) a template stack that’s got to go into the resources folder of the standalone, then I have no choice but to tell the standalone builder about it. To achieve what I want - the ability to close a stack which is in effect a clone of this template and remove it from RAM, just as the IDE is able to do - I will have to delete the reference to to the template stack in the stackFiles property, and rely on the program’s own knowledge of where the template is stored. I’m slightly surprised that this hasn’t come up before. It occurs to me that there may be a solution in renaming the template stack as soon as it is cloned, but I haven’t tried it.
> 
> Finally I should say that the Dictionary entry for ‘the stackFiles’ is a bit inadequate, as it doesn’t mention the interaction between the standalone builder and the property. Maybe this amounts to a bug, if only in the documentation!
> 
> Thanks again
> 
> Graham
> 
> 
>> On 17 Oct 2016, at 12:39, Mark Waddingham <mark at livecode.com> wrote:
>> 
>> On 2016-10-17 11:15, Graham Samuel wrote:
>>> Thanks Jacque - wise words as always. The idea that the delete would
>>> work depending on whether the stack was newly created had not occurred
>>> to me, but seems like a good reason why my simplified tests didn’t
>>> show the problem. I will try again to create a simple demo, and
>>> hopefully I can file a bug report.
>> 
>> Thanks for the bug report (http://quality.livecode.com/show_bug.cgi?id=18612) - I was a bit puzzled about the situation you and Jacque described until I saw your code.
>> 
>> This isn't in fact a bug, just a subtle interaction with the stackFiles property of your 'Master' stack.
>> 
>> The stackFiles property maps names of stacks to filenames - it basically means that when the engine resolves a chunk reference 'stack <name>', if there is no stack in memory with the name <name>, then it will look through the stackFiles property of the stacks in memory to try and resolve it (starting with the stack of the script being executed). Furthermore, it resolves things relative to the path to the stack containing the stackFile line.
>> 
>> So, if you have a line 'DataStack -> DataStack.livecode' in the stackFiles, and if there is a DataStack.livecode file next to the stack containing that stackFiles line; a reference 'stack DataStack' will *always* resolve and load the stack.
>> 
>> Essentially, asking whether 'stack DataStack' or not exists doesn't work, because referencing the stack causes it to.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> _______________________________________________
>> 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