File instability

[cusingerBUSCw5N]

I am so frustrated. I have been building an app - starting with the Ticked Off application and modifying it. I got pretty far on it, saving backup copies so if I made a mistake, I could return to a previous good version.

I have been extremely careful to purge LiveCode when going between the different versions because the card names are the same, etc.

But now, I find that the images folder in Resources that I have been using has reverted to a version from a couple of weeks ago. Within my application, it still refers to the numbers of the images (that don't appear on the image card anymore)- but I wanted to make a change in the image and find that it isn't in the image card - only images from long ago.

I also have had problems because the transition between cards has been inconsistent. I'll make a change - the transition effects won't work. I close the application and open it again - and they will work. There is no logic to it.

I make changes to the application, only to come back and find that the changes are no longer there.

I've put a lot of time into working on this program, but I am wondering if it is at all reasonable to expect a stable product at the end.

Is it me... or is it LiveCode.... and if it's me, what am I doing wrong?

[cusingerBUSCw5N]

I'm missing something basic. I tried to start the whole application over again - new mainstack, new cards...the whole 9 yards. But the new stack is getting images from my old application - even though I made a new substack for resources and put an images file in it and loaded the images for the new application.

How do I get this program to stop connecting itself to old files??????? I am going around and around and around trying to clean up old files, having them revert...

what is wrong???

[Klaus]

I never had this kind of trouble in the last 13 years with MetaCard/Revolution/LiveCode
unless I caused it. So plaese give us more info, scripts etc...

Guessing is too timeconsuming, please spread the word!

[jacque]

I agree, I've never seen this happen so we'll need more info. The only thing I can think of is that you're referencing images from disk and the references are still referring to older file paths.

If you have actually imported images into the stack as controls, then you may have duplicates. The engine will always use the first one it finds in the stack.

But there's not enough info yet to know for sure.

[mwieder]

the images folder in Resources

??? So you're placing your own images stack in the Resources folder ???
Where exactly? And how are you referencing the images in that stack?

I made a new substack for resources and put an images file in it and loaded the images for the new applicatio

I'm having trouble parsing that.

[cusingerBUSCw5N]

Five steps forward...3 1/2 back.... This isn't a question - but just a status on how I solved the problem.

I have learned some basic things. First, I was being driven crazy by formatting/field placement - until I finally figured out that the order that you put the instructions is critical. You need to put width and height first...and then place the top and left. So that helped my sanity a bit.

I think there is an issue with having multiple stacks in the same folders -and copying datagrids from one stack to another. I haven't figured it out yet, but there are other people in the forum that mention this problem. (The problem is in datagrid forms - because they share the same data grid Tempates). I downloaded DataGrid Helper because it apparently helps prevent this - but I haven't figured out whether and how that will actually work. I have multiple stacks because I have found it necessary to keep multiple versions of the same app. Little things have caused the whole app to break and I have had to go back to the point where it was working to try again...Anyway, if I get too many prior versions, the whole thing goes unstable.

Another thing I discovered was that I was putting duplicate items within a card - and that was probably causing a bunch of the problems. This was especially true of groups - In the process of trying to figure them out, I created a bunch of them.

A final thing I discovered was that groups were causing me more pain than they were worth. Doing anything to a group inevitably destroyed it - so I decided to eliminate all the groups and put the code on each of the cards. Specifically, in my cleanup project, I accidentally deleted an image that was part of a group - and for the life of me, could not replace it. In the end, I eliminated the group. Not elegant - but for right now, it was the only thing that helped me move forward.

Anyway - for this problem of instability, I rebuilt my application all by itself in a folder (eliminating all the duplicates and eliminating all groups except datagrids) and all the problems stopped.

[jacque]

I think part of the problem is how stacks are closed and/or removed from memory. LiveCode gets very confused if two stacks with the same name are open at the same time, and messages can be misdirected, objects can appear "lost", and all kinds of mischief happens. The IDE does what it can to prevent that, but there's only so much it can do.

The default behavior when closing a stack is to remove it from view and from the message hierarchy, but to leave it open and inert in the background. If you then open another version of the same-named stack, you essentially have two open at the same time. That can cause worlds of trouble.

There are two ways to prevent that. The easiest is to turn on the destroystack property of every stack (it's an option in the inspector). With that property set, stacks not only close but also are removed entirely from RAM. There's an option in the IDE prefs to set destroystack on every new stack you create; I leave that on routinely so I never have to worry about it. When a stack closes, it's always completely gone.

The destroystack property is left over from a time when computers were much slower and reading from disk took time. Leaving the stack open but inert allowed it to load much faster when you re-opened it. That's no longer a concern, and there's no real reason to keep that property turned on.

Another way to completely remove stacks from RAM without changing the destroystack property is to only close them using the "Close and remove from memory" option in the File menu. That also completely closes stacks.

That should solve some of the duplicate stack issues it sounds like you're having.

[LittleGreyMan]

Jacque,

Thanks for this very pedagogical explanation.

Your reminder is very useful for beginners as there is a lot of concepts to assimilate. I have already been caught by the glitches you describe.

I missed that property in the User's guide, which is definitely worth reading and re-reading.