Crazy Stack File Saving System?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Crazy Stack File Saving System?
I have lost hours of work through an ignorance of the way live code stack files are saved. I think what happened is that I opened an older live=code file (that had been renamed to archive it) that containing the same stack name as the other open stack. I copied the desired items from the older stack to paste it into the new improved version and in the process of saving and closing both files (not sure how or what order I did it), the new stack had morphed into the old one.
Now, after years of computer usage, I assumed that if you "save as..." or renamed a file it became unrelated to any other previous file now with a different name. Evidently, after searching the forums here, that isn't the case. I have lost work on a couple occasions before I figured out something was up. It was very frustrating to find old bugs reappear after days of work and have to try to repeat the "brilliant" steps I had already taken to get back where I was.
I became so paranoid that I started having rule to never open two (even saved as another file name) versions of my project. I close my current work and quit live code, launch live code with the old version file, copy and paste whatever I was trying to recover into new blank project stack, and then save and close it as well as live code. Then I relaunch live code, open my new version and the newly created stack containing the desired stuff to copy and paste, and make the transfer. This is rather time consuming but not as bad as losing a days "inspired" work.
I have read that I could open the two files in different versions of live code simultaneously and that they would be totally independent but haven't been willing to take a chance as I am close to finishing my app. I also read something about renaming the stack in the older file before opening it so that it couldn't be mixed up with the new stack file while opened.
PLEASE:
1) Can someone explain EXACTLY what is happening here so I will be able to devise an INFORMED best strategy to avoid future work losses?
2) Why did RunRev design this to work like this when it is so contrary to must computer users' experience in other applications?
3) What are best strategies used by others to avoid this pitfall?
4) Does anyone else find this confusing and would like Livecode changed to be able to simeltaneously open older renamed files of the same project and be assured they aren't going to risk losing work?
I really love Livecode but this, IMHO, is a big "gotcha"
Russ
Now, after years of computer usage, I assumed that if you "save as..." or renamed a file it became unrelated to any other previous file now with a different name. Evidently, after searching the forums here, that isn't the case. I have lost work on a couple occasions before I figured out something was up. It was very frustrating to find old bugs reappear after days of work and have to try to repeat the "brilliant" steps I had already taken to get back where I was.
I became so paranoid that I started having rule to never open two (even saved as another file name) versions of my project. I close my current work and quit live code, launch live code with the old version file, copy and paste whatever I was trying to recover into new blank project stack, and then save and close it as well as live code. Then I relaunch live code, open my new version and the newly created stack containing the desired stuff to copy and paste, and make the transfer. This is rather time consuming but not as bad as losing a days "inspired" work.
I have read that I could open the two files in different versions of live code simultaneously and that they would be totally independent but haven't been willing to take a chance as I am close to finishing my app. I also read something about renaming the stack in the older file before opening it so that it couldn't be mixed up with the new stack file while opened.
PLEASE:
1) Can someone explain EXACTLY what is happening here so I will be able to devise an INFORMED best strategy to avoid future work losses?
2) Why did RunRev design this to work like this when it is so contrary to must computer users' experience in other applications?
3) What are best strategies used by others to avoid this pitfall?
4) Does anyone else find this confusing and would like Livecode changed to be able to simeltaneously open older renamed files of the same project and be assured they aren't going to risk losing work?
I really love Livecode but this, IMHO, is a big "gotcha"
Russ
Re: Crazy Stack File Saving System?
I sympathize with you, it's a PITA.
This caught me many times for the first few years I was using livecode.
In several cases I lost hundreds of hours of work where the incremental working files saved over a backup copy.
Now:
I never open two similarly named stacks at the same time.
I am very careful to rename a stack internally if I want to work on a backup copy.
Then I check the save as to make sure I know what the file name is and where it is going.
Paul
This caught me many times for the first few years I was using livecode.
In several cases I lost hundreds of hours of work where the incremental working files saved over a backup copy.
Now:
I never open two similarly named stacks at the same time.
I am very careful to rename a stack internally if I want to work on a backup copy.
Then I check the save as to make sure I know what the file name is and where it is going.
Paul
Last edited by paul_gr on Sat Apr 26, 2014 10:20 pm, edited 1 time in total.
Re: Crazy Stack File Saving System?
That's what I'm doing (using v. 6.5.2 and 6.6.1) and it works OK.srbarlow3 wrote:I have read that I could open the two files in different versions of live code simultaneously and that they would be totally independent
That would be very good. You may submit your suggestion here http://quality.runrev.com/ if you like.srbarlow3 wrote:4) Does anyone else find this confusing and would like Livecode changed to be able to simeltaneously open older renamed files of the same project and be assured they aren't going to risk losing work?
keram
Using the latest stable version of LC Community 6.7.x on Win 7 Home Premium, 64bit
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Crazy Stack File Saving System?
There are almost no other apps that allow you to have a different file name on disk from the name of the document. LC is an exception. Since it is possible to have many stacks with different names in the same file, keeping track is a little more complicated. You can't assume that you are saving the same stack you're looking at; you are actually saving the mainstack and all its substacks too. That can be lots of different stack names. To ensure that you are really saving the thing you think you are, you are not allowed to have same-named stacks open, even if their file names are different. The chances for mix-ups are too great. The IDE tries to prevent that from happening but if you open a stack with a script then you're on your own.srbarlow3 wrote:]1) Can someone explain EXACTLY what is happening here so I will be able to devise an INFORMED best strategy to avoid future work losses?
As above, it is possible to have same-named stacks open that belong to different stack files on disk. I don't know any other apps that allow that. The solution is for the LC engine to stop using the short name as an internal reference and start using the long name instead (the long stack name includes the file reference on disk.) This has been requested for some time, but the fact that it hasn't been implemented yet tells me that the current behavior is so intertwined with the basic functionality of the engine that it would be difficult to extract it. Maybe with the current engine rewrite, that will become easier to do.2) Why did RunRev design this to work like this when it is so contrary to must computer users' experience in other applications?
You don't need to go through all the gyrations you list; the only thing that is required is that the stack you do not want to save is removed from RAM. The default setting in LC preferences is to leave closed stacks loaded in RAM. There are two ways to deal with this:3) What are best strategies used by others to avoid this pitfall?
1. To truly close the stack completely, choose "Close and remove from memory" from the File menu instead of just clicking the close box. The stack will be entirely gone.
2. In LC prefs, click the checkbox that creates all new stacks with the "destroystack" setting set to true. If a stack's destroystack is true, it will be removed from RAM automatically when you click the close box in the stack window. The destroystack setting doesn't mean what it sounds like; it just means to destroy the RAM implementation. Your stack will be fine. This is the method I use so that I never have to worry about stray stacks lurking in the background. For stacks that have already been created, you can set the destroystack property in the stack's property inspector for each individual stack.
I think it throws a lot of people, which is why the IDE tries to prevent the situation from arising. But if you ignore the error message, or open a stack via script, then you're apt to run into these issues. LC finds stacks much the way it does objects on a card -- by layer number. Stack layers change dynamically as they are used and you can never be quite sure which one is going to become the target of your "save" command. However, one other thing you can do if you really, really need to have two same-named stacks open (which you shouldn't, but just suppose...) is to manually save the stack from the message box and refer to it by its long name:4) Does anyone else find this confusing and would like Livecode changed to be able to simeltaneously open older renamed files of the same project and be assured they aren't going to risk losing work?
save stack "/path/to/mystack.livecode"
I don't bother with that very often. It's much easier to duplicate the stack file in the OS and just open the copy.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Crazy Stack File Saving System?
I guess that the main thing that trips some of us up, is that renaming the filename of a copy will not stop the copy using the original filename if the name of the stack is not changed internally.
example:
Make a new stack, internally name it "original".
Save it--will save as "original.livecode".
Now save as new filename "copy.livecode".
Close Livecode.
remove the original file from the folder.
Open copy.livecode and save it.
It will save using the name of the original file.
You MUST rename the stack INTERNALLY to stop this.
I'm presuming this is not just a Windows thing.
Paul
example:
Make a new stack, internally name it "original".
Save it--will save as "original.livecode".
Now save as new filename "copy.livecode".
Close Livecode.
remove the original file from the folder.
Open copy.livecode and save it.
It will save using the name of the original file.
You MUST rename the stack INTERNALLY to stop this.
I'm presuming this is not just a Windows thing.
Paul
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Crazy Stack File Saving System?
I see. That's because the "filename" is actually a property of the stack itself. When saving, it saves to the stored filename. To make it save to the new file:
set the filename of this stack to "copy.livecode"
Then a regular Save will work as you expect. When you do a "save as" from LC's File menu, it does this behind the scenes for you.
Yes, it's confusing. The filename property is also linked to the fact that the internal stack names don't need to match the disk file name.
Edit: Just re-read your post. Apparently LC revises the filename internally if you change the stack name. I think this will only work if you change the mainstack's name; substacks wouldn't matter.
set the filename of this stack to "copy.livecode"
Then a regular Save will work as you expect. When you do a "save as" from LC's File menu, it does this behind the scenes for you.
Yes, it's confusing. The filename property is also linked to the fact that the internal stack names don't need to match the disk file name.
Edit: Just re-read your post. Apparently LC revises the filename internally if you change the stack name. I think this will only work if you change the mainstack's name; substacks wouldn't matter.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Crazy Stack File Saving System?
Thanks Jacque,
Much appreciated. First time I've seen anyone explain this in detail.
Paul
Much appreciated. First time I've seen anyone explain this in detail.
Paul