Well, thanks for all the comments regarding failing to save the data stack distributed with a compiled splash stack. Each case is different. In this case, I have to actually go by my promise to not install anything on the target machine that is not visible inside my app folder. The user can just remove the folder and that's it - by agreement. So, that actually disallows even storing anything else in any writable directory in this particular case.
The data stack uses data separated from UI and data is read-only. The user saves data to a text file. That all works well. The saving of the "data" stack that includes the separate UI has mainly one purpose: to allow the user starting from where he/she stopped working with the application. But this is not crucial and I will simply not save anything. The stack will be as is. I just feel that we should know what the problem is that corrupts the stack when saving and the original stack filename is appended with the tilde character? Well, corruption is a big word here since the stack itself is not corrupted or does not appear to be, but something is not right. It is more a principle question now. As Curry mentioned, it happens elsewhere. Is there any way to detect and catch an error when saving? We are deviating a bit from the subject here which is "Windows Definer and AV software". Still, there could be an issue related. Saving either from the IDE or saving the compiled in any case (with or without corruption) takes way too long time. My tests disabling Windows Defender did not change this but I still do not rule out that there could be something related to AV. It needs further testing, maybe also on other machines. And I can not ask clients to disable Windows Defender or change the Defender settings anyway. I have no control over such machines and it is a big company with some users using my app. They are mostly illiterate even to open Windows Defender or they are not permitted to change any settings. But generally said, I would also prefer to go with a proper installation tool, read from and write to files in the AppData or Documents directory and keep data separate from the stack -- even though if this is possible in principle, it should not create problems also using stacks for data storage. In many cases, it is a very simple straight-forward solution as everything is easily accessible. A stack is just not a good database solution if data is well structured and there is a lot of data. Roland _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode