R.H. wrote:
> 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?
Agreed. If the engine has a problem writing stack files, that would
prevent us from using LiveCode.
The trick now is to pin down the cause of the issue you've experienced.
Since we don't see many reports here of errant stack saves, it seems
this will require some sleuthing to pin down the specific combination of
factors at play.
> Is there any way to detect and catch an error when saving?
All I/O, whether socket or disk, whether stack files or any other
format, is ideally accompanied by error-checking, e.g.:
save stack tStackFilePath
if the result is not empty then
answer "Couldn't save document ("& sysError() &")"
exit to top
end if
The sysError function is especially useful there, delivering the error
number the OS provides to describe the specific reason the file could
not be written.
> 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...
How much is "too long time", and what's in the file?
The number of cards may be particularly relevant for save time, perhaps
number of substacks if there are many. File size when written
successfully would be good know too.
> 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.
I'm with you, very disinclined to encourage users to turn off built-in
security features.
I haven't done more research on this in weeks, but back when I did the
many other apps affected by this were of such a broad variety no clear
pattern was self-evident to me which would explain how LC could be among
them.
As time permits I may do some more reading around the web to see how
other vendors are coping with this.
> 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....
More than OS-recommended practice, often essential. All user data
should be in user space.
> A stack is just not a good database solution if data is well
> structured and there is a lot of data.
Agreed. If you need a DB you should use a DB, which will have its own
binary file format(s). (But of course then the question is which type
of DB: relational, document store, graph, or something else?)
There are almost as many file formats as their are document-producing
applications. No singe file format can accommodate all possible types of
apps, so we use the format best suited for the type of app we're making.
The bad thing about file formats is that there is no one-size-fits-all
solution, so we have to make choices about what's best for the task at hand.
The great thing about file formats is that there is no one-size-fits-all
solution, so we get to make choices about what's best for the task at hand.
:)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
[email protected] http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
