LiveCode Forums.

At least it doesn't seem to do so predictably. I have three data stacks in my Mac OS X application: Questions.rev, Settings Saver.rev, and Teams.rev. There's a copy of these three located in the application package, and they are copied to the Classroom Quizshow (the name of my app) folder within the user's /Library/Application Support folder at application launch if they're not already there. That works fine. Then I also have some other trickiness because I'm updating the copy of Settings Saver.rev that's possibly already in a user's Library folder. The root of the problem is no doubt that I have two copies of each data stack in two locations, and these pairs of stacks, of course, have the same names.

Through the debugger, I've determined that what doesn't work is closing the stacks. The problem is that, although I have the three (six, actually) data stacks' destroyStack set to true, they don't actually close (at least not immediately) when I issue a close stack command. Then, when I try to access them again, I get the error message saying:

A stack with the same name as the one you are trying to load is already open.
Before loading /Users/Steve/Dropbox/CQ 8.6.6/CQdata/Settings Saver.rev, what do you want to do with the stack: /Users/Steve/Library/Application Support/Classroom Quizshow/Settings Saver.rev, Settings Saver?

I'd already told that stack to "close stack". I've read the caveats in the "close stack" documentation describing situations in which stacks might not immediately close, but they don't seem to apply to my case. Also, the script doesn't work in stand-alone form, either. In the IDE it throws up the error message then freezes LiveCode, requiring a forced quit. Here's the example script in which "close stack" isn't working. I should note that, in an unsuccessful attempt to solve this problem--or at least to make the script easier to follow for me, I now refer to the six stacks by their absolute file paths instead of relying on changing the defaultFolder as I previously had. The variables such as gLibraryFilePath_Questions contain these absolute file paths, and I've verified that they're hitting their targets.
...
end if
save stack tFilePath_Settings_Saver
close stack tFilePath_Settings_Saver
if AppStore = "yes" then
if gUpdateSettingsSaver = "yes" then
local tSource
local tDestination
local tCommand
put gLibraryDefaultFolder into tDestination
put gPackageFilePath_Settings_Saver into tSource
put ("cp "&quote&tSource&quote&&quote&tDestination&quote) into tCommand -- There's no -n in the command, so it WILL overwrite the existing file. http://ss64.com/osx/cp.html
get shell(tCommand)
end if
save stack gLibraryFilePath_Questions
close stack gLibraryFilePath_Questions
save stack gLibraryFilePath_Teams
close stack gLibraryFilePath_Teams
else -- AppStore <> "yes"
save stack gPackageFilePath_Questions
close stack gPackageFilePath_Questions
save stack gPackageFilePath_Teams
close stack gPackageFilePath_Teams
end if
end saveDataStacks


The first "close stack" (close stack tFilePath_Settings_Saver), is intended to close the copy of Settings Saver.rev within the Library/Application Support/Classroom Quizshow/ folder, and, indeed, the "save" command on the previous line does save that stack as verified in the Finder.

When stepping through the code, I can see that stack is NOT closed after executing that step. I determine this by looking at the Application Browser after closing and reopening it to refresh its view. However, by the time I reach the final line of code pasted above, Settings Saver.rev IS closed. The other two "close stack" calls in the script above do NOT close their stacks, at least not by the time we reach the end of the pasted script.

So let me try to boil the problem down: Because of some tricky stack copying I have to do to get the data stacks from their initial home in the application package to their permanent home in the Library folder, I have pairs of stacks with the same name in two different places. I would think I could get by with this perhaps unadvisable situation by diligently closing the stacks after each use, but "close stack" isn't following orders. Help?

One more thing: I'm using LiveCode 5.5.4, build 1502.

A little hard to figure out exactly what you've got going on there, but... are the data stacks substacks of your main application?

No they are not. If I could figure out how to post a picture in this forum, I'd show you a screenshot of the Application Browser, but no, they're not.

Try the "Upload attachment" tab underneath the Submit button row. Take a screenshot, Browse to the screenshot image, and Add the file.

Here's a screenshot of the Application Browser, submitted to show that my three data stacks (at the bottom) aren't substacks of my main application stack. If they were, as I understand the documentation, my data stacks would NEVER close until the main stack closed, and that's not the behavior I'm seeing.

To recap my problem, "close stack" isn't closing my data stacks. The pasted script fragment in my original post isn't really of any importance except for the description in that post about when the data stacks did (and mostly didn't) actually close.

stephan wrote:
A stack with the same name as the one you are trying to load is already open.

This error message is only in the IDE?
Have you tried and see what happens in a standalone?

Sure... that does not excuse LC, if it is an LC problem.

Simon

In stand-alone version, the error message doesn't appear, and the stack doesn't freeze on close as it does in the IDE (the code that saves and closes the data stacks is called from the closeStack handler of the mainstack.) However, the data stacks aren't saved properly, which makes me think the same problem occurs in stand-alone—it's just ignored rather than throwing an error dialog.

I've thought about solving the problem by giving the data stacks stored in the app package different names, but it would be easier if I didn't have to resort to this work-around, and it seems like we ought to get the "close stack" command working predictably if it's a LC problem and not something I'm doing wrong.

Hi Stephan,
Let me simplify the problem so that I can understand it:

e.g. I'm a user using your app. I click on a button called Settings (start using stack "Settings") to change the font used to Arial and see that the UI has updated. I close the settings dialog (Settings.rev) and continue working with your app. Then I want to change the font back to System (during the same session) and so I click on the Settings button again.
And that is where the error occurs?
I suppose since it's a Preference file you also open it when you first run the main app.

Any chance you could make up a new Main stack with nothing but a button that opens/closes your Settings.rev, showing the error, and post both here?

I'm guessing in Settings.rev you have something like:
on closeStack
save me
end closeStack
Maybe that should be further up the message path?
Too many possibilities without your stacks to look at.

Simon

No, it works like this: the settings are loaded from the data stack Settings Saver.rev into global variables at launch, and at application close, they're saved again to the Settings Saver.rev file. It's as simple as that, and that works fine.

But I've recently gotten fancier because of the Mac App Store requirement to save data in the ~/User/Library/Application Settings/Classroom Quizshow/ folder. I have a copy of the Settings Saver.rev file in the application package. In the Windows standalone, the app simply uses this copy of Settings Saver.rev (in the app folder in that case), but in the Mac OS X standalone, the copy of Settings Saver.rev in the app package is copied to the Library folder if it isn't already there, and it may also be copied over if it's determined that the file needs to be updated (as it will have to be in my next release).

All of that may seem convoluted, but I think the actual problem is quite simple. I believe this need to have two copies of the Settings Saver.rev file has uncovered a previously unnoticed LC bug, namely that "close stack" doesn't reliably close the intended stack, at least not right when you issue the command. Because of the two copies of Settings Saver.rev, I'm needing to close these files after each use to avoid having two stacks of the same name open, and I'm finding "close stack" isn't reliably and predictably closing them for me.

Does that make sense?

Try "delete stack" instead of "close stack". That removes it completely from RAM. Don't worry, it doesn't delete the file, that's a different command.

Hi Stephen,
Is "delete stack" working for you?
Jacque gives way better advice than me.

Simon

Thanks to both of you. I'm not at home and am unable to test "delete stack" yet, but I will.

I've found evidence that this is an old problem. I'd say it's a bug. Here's someone with the problem in 2004: http://lists.runrev.com/pipermail/use-l ... 38013.html

Here's someone with the problem a couple months ago: http://comments.gmane.org/gmane.comp.id ... ser/184596

That 2004 post (1st of the 2 links above) seems to show that the "close stack" command has been known to be unreliable for almost a decade now, yet the LiveCode dictionary still touts it as a-okay. I'll try the "delete stack" handler, and that 2004 article gives me hope it may work, but it sounds like "close stack" with destroyStack set to true is supposed to do what I want. Shouldn't this bug have been squashed long ago? As I understand it from the 2004 post, "delete stack" really is designed to DELETE a stack (scary and not what I want), and it's only usable as a work-around for the unreliable "close stack" because if the stack being "deleted" is a main stack not a substack, it won't really delete it.

It isn't really a bug, "close stack" is behaving as it is supposed to. Any time you need to read a part of a stack, it needs to be opened again. In the first link, the stack was closed but then the script checks to see if there's a named field in it, so it gets opened again. In the second example, the problem was in trying to delete a stack from RAM that had already been deleted from disk (preventing normal housekeeping and causing an unfortunate crash, hopefully fixed by now) and, once that was changed, in trying to delete the stack from memory while its script was still running. You can't do that; as long as a script is running the stack needs to remain open and the engine enforces that. Any access or reference to the stack in any way will prevent it from closing, and will re-open it if it's already closed.

When I need to do something similar to what you're doing, I use the url keyword to make a new copy of the stack:
That happens at the OS level and doesn't involve LiveCode at all, so it doesn't get opened. After you've gathered all the info you need from the original, delete it from RAM, open the new one, and set it up. Actually, you don't even need to specifically open the new one (though I usually do anyway) -- just setting any property in it or referencing any object will open it in the background without putting it into the message path. If you specifically open it, it will be in the message path, so which way you do it depends on how you want it to behave.

Oh, also, about the "delete stack" command. It isn't there just to overcome a bug, it's useful in its own right and I use it frequently. There are times when you have a stack open and you want it to remain in RAM but out of the message hierarchy (I often do this with prefs stacks so they are accessible but out of the way,) so you leave its destroystack false. When you're really done with it and you want it to go away, you use "delete stack" to cleanly remove it.

I use it from the message box all the time too, for a fast way to remove a stack without having to go through the "close and remove from memory" menu item, which just issues a "delete stack" command, but puts up a warning dialog that slows me down.

The caveat about deleting substacks is true. If you delete a substack, it is removed from the stackfile, so you want to be sure you only use delete stack on mainstacks, unless you really do want to remove a substack completely and forever. But if you realize you've done the wrong thing, all is not lost if you haven't yet saved the stackfile -- just issue a "revert" command and it all comes back.

Don't forget "stop using stack "myStack""
That will stop any lingering messages.

Just checking

Simon