LiveCode Forums.

This has happened ever since I moved to v.8.1.6. Never before.

This dialog always comes up while the standalone is being built, the one where a stack may still be in memory: The stack in question has its destroyStack and destroyWindow set. The stack has been closed explicitly for the build. As if that matters, because this dialog pops up all the time, though intermittently.

It does not seem to harm anything, I am just wondering...

Craig Newman

The LC Standalone Builder never alters your stack beyond saving it, but instead works on a copy of your stack to copy includes, clear properties, install revCommon and some other libs, etc. To avoid name conflicts in the IDE, it closes your working stack and builds with a copy it produces before re-opening your original stack to resume working.

Richard,

Sounds prudent. But if it closes the working stack, and that stack has all its "destroys" set, why the dialog? Never saw this in 6.7.

Craig

dunbarx wrote: ↑

Wed Nov 29, 2017 8:36 pm

Sounds prudent. But if it closes the working stack, and that stack has all its "destroys" set, why the dialog? Never saw this in 6.7.

Many of the differences in behavior between v6.x and later versions are bug fixes, even if they don't appear immediately obvious as such. It would seem this is one of them: destroyStack only governs if the stack remains in memory after closing; cantModify should tell the IDE not to bother asking for a save before closing the work stack when making its standalone copy.

I don't remember ever seeing that dialog when building with LC 8. I do have a habit of manually saving the stack before building though, so maybe that's why.

Thinking about this more...why close the stack? In fact, I can't think how you could build a standalone from a closed stack that has been removed from memory. Or do you mean you close a substack? (That shouldn't matter.)

Jacque.

I also always save everything before building a standalone.

The splash stack does not seem to need to have the working stack (or its substacks) open in order to find it. The "Stacks" pane in the Standalone Applications Settings holds it, of course, but I can open the splash stack alone in a new session with no access to the "working' stack, and it builds just fine.

Craig

I see, you're building from a splash stack. That's the only one that needs to be open. If the error message refers to a substack of the splash then I'd call it a bug.

Deal is, I've built from a mainstack with substacks many times and haven't ever seen that error. Odd.

No substacks in the splash stack, just another stack file, a mainstack with its own substacks, attached. That is the one, always, that the dialog refers to.

Craig

It's hard to say what's going on in that case, but the most logical explanation is that the stack is still open in RAM. You could check in the message box: there is a stack <short name> before building.

Jacque.

check in the message box: there is a stack <short name>

I will try that, but I mentioned I can start a standalone build in a brand new session, with only the splash stack open. Perhaps the process opens the other stack as part of its usual machinations, but then does that mean it opens it twice?

Craig

If a script references any stack in the stackfiles list, LC opens it in RAM. So if any of the startup / open* handlers refer to those they will be open.

When the standalone is built, LC (probably) has to open a copy from disk and you get the warning.

Jacque.

I get that the standalone exe. would open the stacks of any and all attached stack files. But I believe, as a test, I commented out the exe. stack script, where there is a line opening the "working" stack. So there are no handlers referencing that working stack. I will check that again on Monday.

So say that because it knows all about attached stack files it opens them as a matter of course, even if no handler exists that references it. I still do not know why it is telling me that the stack is already open, and what do I want to do about it. This never happened in v.6.

So v8 is different. OK. But I am the only one seeing this, I think.

Never any damage done, but unsettling. I just want to know if this is a matter for the team.

Craig