Really closing a stack

Graham Samuel livfoss at mac.com
Mon Mar 4 14:17:26 EST 2013


Wow, what an insight! That also explains the fact that I got messages from the IDE saying there was a naming conflict immediately after I thought I had eliminated the stack from RAM. You live and learn: perhaps we need to get some of this into the LC dictionary - I'll think if I can write a sufficiently clear comment.

Brilliant, Jacque.

Thanks very much

Graham

On 4 Mar 2013, at 19:48, J. Landman Gay wrote:

> On 3/4/13 9:21 AM, Graham Samuel wrote:
> 
>> FINALLY I did something which I hadn't thought would have any
>> influence at all on the outcome - the 'Killer' stack has a reference
>> to the "dataStack" stack in its 'Stack Files' list: I added this to
>> make it easier for Killer to find the other stack. When I deleted it
>> and made the 'kill' handler use the full path to the stack it had to
>> delete, bingo, it worked - in my script and in the IDE and in my
>> standalone. I have no idea why and I don't know if it will transfer
>> to my real application, where I don't remember messing with 'Stack
>> Files' at all. I'll see. Meanwhile if anyone can see the logic of
>> this change, please tell me.
> 
> If the script provides a full file path when referencing a stack, "there is a stack" will return true. It's the same as checking if there's a file at that location, only it discriminates only for stack files.
> 
> If you've got the short name of a stack linked up to a stackfiles list, every time you refer to the short name, the engine will substitute the long file path instead. So basically your script was asking if there's a stack on disk, not in RAM. In order to check, the engine actually opens the stack, which puts it back in RAM.
> 
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> 
> _______________________________________________
> 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





More information about the use-livecode mailing list