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.
> On Oct 17, 2016, at 07:07 , Graham Samuel <livf...@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
> Thanks again
>> On 17 Oct 2016, at 12:39, Mark Waddingham <m...@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
>> 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 Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 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