Left-overs from a past life....

[RossG]

My current project is a modification from one I did some years ago.

To the best of my knowledge I removed the code, buttons etc. I didn't
need but there's some stuff I can't find which is annoying me although
not affecting the programme

Sometimes I open the original programme, close it and then open the
new one. At that point I get an alert that there's another copy of this
unwanted item already in memory. What's it doing there? I closed the
programme. It should have had the decency to go with its code, stack,
button or whatever.

You could say it's academic but still annoying.

[Simon]

Hi RossG,
From the Project Browser right click and select "Close and remove from memory"

Simon

[RossG]

Simon

I am so used to just "Closing" that I don't think of the other option.

Why would one want to "Close" without removing from memory?
Does leaving it in memory have some purpose?
If not then "Close" should remove it from memory.

In the distant past ('80's) it was considered uncouth for a
programme to leave its left-overs in the (then very limited)
memory. The standard closing statements in a FoxPro 2 script
were:

Close all
Clear all
Delete all

Which did the whole thing in three lines.

And of course I can blame FoxPro for my constant use of
endif.

[dunbarx]

Hi.

Set the "destroyStack" and the "destroyWindow" to "true" in the property inspector. See these in the dictionary. They are not as draconian as they appear.

Craig Newman

[FourthWorld]

Why would one want to "Close" without removing from memory?
Does leaving it in memory have some purpose?

It's very rare that you'll find programmers of any development tool going out of their way to design features that have no purpose.

In LiveCode, stack files are cached for performance, allowing them to be used within the session without having to load and unpack them from disk each time, unless that's something you explicitly want to do.

For example, if you made a library of user interface stacks like dialogs or document templates, those would only need to be unpacked once and would appear instantly every time they're called after that.

In the distant past ('80's) it was considered uncouth for a
programme to leave its left-overs in the (then very limited)
memory.

RAM was much more expensive in the '80s, so swapping from disk was an unfortunately frequent necessity.

Still, like any usefully flexible tool LiveCode leaves the developer in control of this caching:

The standard closing statements in a FoxPro 2 script
were:

Close all
Clear all
Delete all

Which did the whole thing in three lines.

Even simpler in LiveCode:

Like Craig said, you can set the destroyStack and destroyWindow properties of the stack in the Inspector (or via script if you prefer). Once saved those properties are persistent, so going forward instead of FoxPro's three lines you'd only need one:

close stack <stackName>

[jacque]

Another example: I have a project that downloads many large stacks from a remote server on demand. These are opened and closed repeatedly during a session. If the stacks were removed from RAM on close, they would need to be re-downloaded every few minutes. For that reason I have intentionally left destroystack set to false on those stacks.

Normally I have my LC prefs set to create all new stacks with destroystack set to true. This case was an exception.