Yesterday's save as an xml (local) will load. Today I saved again, and then had to restart my browser (not Snap! related). When I tried to open today's file, it just sits at "Opening" and nothing ever happens. Today's file is 3K larger than yesterday's file. It appeared to work to my satisfaction when I saved it. My hypothesis is that something didn't get properly written in XML.
I had made some breakthroughs. I can try to retrace my steps with yesterday's file, but I hate to have lost my work.
I use Chrome on Windows 10. I do have the string library loaded, although I don’t make extensive use of it. I had a really hairy ask within an ask construct in one procedure. That’s my main suspect. When I recoded that part I used simpler code.
yep, I can confirm that the culprit for the broken XML is the string library. I shouldn't have pulled it, sorry. Just curious: Can you tell me what you need the string library for? Would you be able to manage without it? I'm planning to remove it, like ... now ... to prevent other projects from breaking.
One use was to return the base name of a clone. For instance, I needed just “clone” rather than “clone(2)” in a sensing operation. All uses were in short functions classed as sensing. I may have avoided that when I recoded by getting the parent of a clone and then getting that object’s name.
I’ll test carefully when I pick up the project again later today. I should be able to remove that library now that I know a bit more about Snap! . Although I am an experienced programmer, I am a Snap! novice. I gravitate toward list processing and OOP, and operating on strings is just something I expect to do.
Nah, let me look some more into this. I think we can get it all to work, including the string library. I might either make a quick patch or make the recovered project available to you, then things should be fine again.
The main problem is the presence of several stage watchers for a no longer existing global variable named "Card". When I remove these obsolete watchers your project loads just fine. I'm puzzled by how more than one watcher for that variable was produced in the first place, especially with that variable no longer being present.
Just an idea: Did you perhaps use the "rename all" feature to rename several other global variables each into "Card"?
In the version I produced after the problem yesterday I finally managed to get rid of Card entirely, moving it into a script variable.
I have been striving to improve scope issues. Since I am developing I have a lot of watchers. I periodically remove them all and create a new set when debugging. I must have had a bunch present when I saved that were leftover from my latest debug session.
lots of watchers are what they're meant for The part that I can't reproduce (and that poses the problems) is how more than one watcher named "Card" ended up onstage (that shouldn't be possible), and how even after you "got rid of the Card variable" that watcher wasn't automatically removed (that should also not be possible).
When I was working (now retired) I seemed to excel at stumbling into edge cases when testing code. So be warned.
I had an object Hearts that used Card as a global. Much later I duplicated that object and renamed it to Spades (then just edited the costumes and renamed one or two other things). But both used Card.
Now I use a script variable myCard, so the two don’t get tangled. My clones don’t need to communicate with each other, but they do need to sense things about whatever is being touched.