Copying a corrupted stack on a new clean one

[synto]

Hello everyone, once again I appeal to this wonderful forum in which I find a lot of solution and help to my various problems, thanks to all of you

This time, it's about a corrupted stack, i think, cause it can't open the Android camera view when i place a barcode scanner on this stack, even if i delete all other cards and objects, even if i place the scanner widget on a substack.

But when i copy the card with the Android barcode scanner on a new stack with all the same standalone settings, the camera view is opened for the scanning.

So something wrong with this stack, and i want to copy all my work (5 cards, 1 substack for datagrid templates) on a new clean stack, please how can i do that ?

[synto]

Here is the corrupted stack for testing purpose

[dunbarx]

Hi.

With only five cards, copy them by hand to a new stack. For the subStack, just reset its mainStack in the inspector to the new stack.

Craig

[synto]

Ok i will try this. Is there a way to copy an entire card, substack to another stack ?
Cause i copy all the controls to a new card, then the script, etc...
And i can't copy all the substack datagrid templates with their row templates, and all the datagrid things...

[bogs]

Doing it this way should, far as I know, move everything involed with the card from stack to stack -

[synto]

This is what i was searching for... You saved my life !
Now my stack is clean, and the scanner is working !

Thank you very much !

[FourthWorld]

FWIW, if you can open each of the cards in the original stack it probably isn't corrupted.

True file format corruption is extremely rare in LiveCode, and when it occurs it most often prevents the stack from being opened at all.

My hunch would be the original stack had something missing in the standalone settings (I realize you'd written you checked that, but with so many settings I wouldn't be able to offer such assurances unless I'd written a tool for that, and I've been using LC for twenty years).

If not that, perhaps there was something specific to the object that wasn't operating correctly that caused the issue.

Hard to say what the cause of the issue was without some investigation I'm not in a position to undertake, but whatever it was it probably wasn't stack file format corruption.

It's too bad that so many other complex formats like HyperCard and FileMaker are so prone to corruption that they establish expectations of corruption for any non-obvious error, prompting explorations into solutions that may yield a good result but prevent us from understanding the actual root cause.

If it helps, remember that LC differs quite starkly from corruption-prone formats by it's writing method: programs where corruption happen often usually use paged reads and writes, where portions of the file are modified without touching anything else in the file.

This is more challenging to get right than LC's method, which always loads the complete stack file into memory, and writes the complete file fresh with each save. Barring an interrupted write, there are very few possible circumstances which can cause the write to go bad once it's been completed and it's checksum verified, which happens before the save command returns.

All that said, it certainly never hurts to learn new ways to work with card objects, so it's not like the exercise wasn't worth the time in this case.

[dunbarx]

Richard.

Just for old times...

It's too bad that so many other complex formats like HyperCard..

I get problems with LC now and then, never a corruption but rather a crash forcing a reload.

But I do not think I ever saw more than a couple of similar issues with Hypercard, and like you, I started using that in 1987, and still use it daily. I am annoyed when LC crashes; I would be astonished if HC did.

Craig

[bogs]

This is what i was searching for... You saved my life !

Well, seeing as how your such a good friend and all, I'll only charge you half my nominal surgical fees...

Just to add my .000000002 cents on the topic, I'm pretty sure Richard is right, that it wasn't actual file corruption, and for the reasons he listed, but I'm glad it helped you out

My additional .0000000000002 cents would be that, since I word in a wide range of versions from HC to 6.x, Craig's observations are valid as well. It seems (at least here on my machine) that with the exception of **3.x, the farther you are from the ***base version the more ... unexpected things I guess, happen.

i.e., Hc has rarely if ever given me an unexpected event like a crash, or a field goof-up, or whatever. Of course, Hc was designed and implemented for one OS by people who worked for the company making that OS, I'd expect that to work almost flawlessly, or at least as reliably as the OS it is running on.

** I've had exactly 2 sessions in 3.x that haven't been interrupted by it disappearing like a fart in the wind. I expect this is a result of the engine, as it operates on the various 'nixes, I have this happen far more likely outside of pure Debian, but haven't isolated exactly what causes it.

** I take the base version as Mc 2.1 which is the oldest version I have available, however, Rev 2.2.x (next oldest version I have) hasn't crashed on me as a result of the IDE (I did crash on two instances where my code caused the issue). However, the script editor is almost useless on 'nix in this version and below.