(destroyStack) Ok, Maybe I know that What, but not the Why...

[mbossiere]

This may seem dumb, but why is this property available to set?
closeStack means close stack, so under what circumstances would I want to leave it in memory?

Also, I save my projects to a local folder which is also a cloud folder (Dropbox) and I will usually be very careful to "quit" (close) projects or the entire LC app on one machine if I know I might be opening that project on my other Mac -- for obvious reasons: mostly to avoid the nightmare scenario of making changes to the wrong copy of my stacks.

Would I be smart to make destroyStack true as a rule?
And what's a compelling example of why the LC engine makes this property optional in the first place? I understand the memory-saving reason stated in the Dictionary, but who does this apply practically?

And, one last thing, why on earth has this property been named to terrifyingly? It's always scared the hell out of me!!

[dunbarx]

Hi.

I always do, because if I close a stack I invariably want it to actually go away. But others may close a stack and yet want to keep it close by, in a sense. Possibly to access handlers in their stack scripts, for example? Such stacks might be considered more like a stack that is hidden, rather than dismissed?

Craig

[dunbarx]

A long time ago the actual name of that property caused confusion, if not consternation among some users here. I wonder if it was a sort of joke to name it that way.

Craig

[richmond62]

I thought THIS did 'IT':
-

[dunbarx]

Richmond.

It does indeed do it. I think the OP wanted to know the practical difference between leaving a stack in memory when closed, or not. There are differences in those two conditions.

Craig

[jacque]

The term is a Unix one, there's also a destroyWindow since that OS separated a window architecture from its content. MC was originally 'nix only and those terms made sense in that context, though not so much anymore.

[mbossiere]

Thanks Jaqueline, interesting history of the property name! I have always tiptoed around destroyStack even though I felt pretty confident I understood it's purpose.

My trouble is often that I run a function of my own making called copynow(), which optionally creates archives of the current stack (applying a filename timestamp) at various times such as openStack, closeStack and whenever I'm about to muck around with an important script.
It adds a new file to a designated 'archive' folder ("wildcode.livecode", for example, gets saved as
"arch.25-01.24@142036.wildcode.livecode" or "arch.25-01.14@213755.wildcode.livecode", and so forth).

If I run into a dead end and want to open a recent archive it's quite simple, even via a script, but because of destroyStack I am confronted with a mind-bending dialog box asking about purging and saving (I'm sure we all know it!) because of course the internal stack name of all the archival copies of my stack are simply, in this example, "wildcode". I guess this is unavoidable.

But for this reason, if I set destroyStack to true I understand I will continue to be presented with destroyStack's dialog wordgame if I'm calling for the archival stack from within it's master stack (but that's OK I guess - unless someone knows a way to skip that). But still, when I "close" a stack and request a recent archive of said stack I would be spared the lengthy riddle in those cases.

I've just always wondered I guess about the scary terminology and convoluted interactions we must deal with when it comes to destroyStack. And still not entirely clear why it's a user choice in the first place.

Marc

[FourthWorld]

Related:

#3932 - Add new "purge stack" command
https://quality.livecode.com/show_bug.cgi?id=3932

#1061 - Can we be done with stack name conflicts?
https://quality.livecode.com/show_bug.cgi?id=1061

#18793 - Internal topstack evaluation returns wrong stack reference when two stacks are open with the same short name
https://quality.livecode.com/show_bug.cgi?id=18793

[dunbarx]

mbossiere.

If you make two stacks, "A" and "B", and place a handler in the script of stack "B" that does something like:

Code: Select all

on xxx
   answer random(999)
end xxx

and with stack "B" in front you invoke "xxx", you get a random number in the dialog box. If you place a button in stack "A" that sends "xxx" to stack "B" you also get a random number.

If you close stack "B" with the "destroy" gadgets false, you can send "xxx" to stack "B" and still get a random number. That stack is closed but still in LC's memory. But if you set those properties, LC throws an error since it know nothing about stack "B" any longer.

That is at least one difference, and why the user is given a choice.

Craig

[jacque]

I've just always wondered I guess about the scary terminology and convoluted interactions we must deal with when it comes to destroyStack. And still not entirely clear why it's a user choice in the first place.

Back in the ancient days when computers were slow and plodding it could take a noticeable delay to open and populate a new window and its content. If the window was retained in memory it could reappear instantly. So the reason to retain all or some of the window dates back to antiquity.

It's largely moot now, though I suppose in some cases it might be useful if you have a custom window shape or a huge amount of data to load. I generally keep the LC pref that automatically destroys stacks when closed. If you don't want to set a global preference you can manage each instance independently:

Code: Select all

close stack X
delete stack X

[mbossiere]

Thank you. I cut my scripting teeth using Hypercard on a 68K mac (a Plus) and I do remember the need to maximize speed with memory tricks.
Craig, your example is useful thank you. Like Jacque I think I am more inclined to purge a closed stack to save confusion if nothing else but I guess I can see there might be some utility in having a stack remain in the message path but again.. potentially confusing.
I guess in my mind closed is closed and open, open.
Jacqueline, you've reminded me of similarly alarming bit of LC nomenclature: delete stack. It's another I have never taken advantage of and in this case it seems for some reason. The Dictionary states that is will simply purge a mainstack which seems excellent and useful, but it further states that if it's target is a substack it will actually DELETE that! As a result, 'delete stack' appears to have two possible effects - one very useful and the other potentially pretty deleterious (literally)
Thanks to both of you for your explanations.
Marc

[jacque]

You're right, I was assuming your stack was a mainstack. I did make that mistake once or twice when a substack was in focus but fortunately I hadn't saved anything so no harm done. My suggestion probably should have said "delete stack <mainstack>". Or better, only delete if the stack isn't a substack.