Fwd: windows defender issues? & other AV
roland.huettmann at gmail.com
Sat Jan 19 08:02:45 EST 2019
Sorry, I must send a correction, I meant MegaBytes, not Giga Bytes (typing
This is sentence needs correction:
"The size of the stack file is nearly 4 MB, probably mainly because of some
---------- Forwarded message ---------
From: R.H. <roland.huettmann at gmail.com>
Date: Sa., 19. Jan. 2019 um 13:56 Uhr
Subject: Re: windows defender issues? & other AV
To: LiveCode Runrev.Com <use-livecode at lists.runrev.com>
Ref. To Mark Waddingham's suggestion:
/* Dear Mark, let me make this side note: Your insight and your comments
here, also in general, cannot be praised enough. I am a fast typer and a
slow reader, so I have to discipline myself to carefully read. But your
comments always catch my attention and I always read very carefully what
you are writing. You know about the engine and details with a fantastic
ability to let others understand important details based on a huge
knowledge base you have acquired. I needed to say this. We are writing here
because all users of fantastic LiveCode should profit. */
Regarding the crashing stack in Windows when not saving correctly ON SOME
USER MACHINES, unfortunately not on mine, I already have sent the stack to
Heather two weeks ago. I just wanted to read all the comments before I pay
(payment is by the hour). She has already quickly tested the main stack on
a Mac (not Windows) and did not find issues. I try to investigate more
before actually submitting an order.
My main stack has 58 cards. The stack has two small sub-stacks also used as
UI for settings. There is one card dedicated to internal resources (images,
etc.), two cards are user interface cards, the rest are data cards for a
technical product and "read-only". The user only sees the UI cards of
course. The stack script has 1500 lines of code. There are additional maybe
1000 lines of card scripts and really only some other scripts in buttons
(often behaviours), I am not using script-only stacks. The size of the
stack file is nearly 4 GB, probably mainly because of some technical images.
Testing the "save" process: I have no error when saving on my machine. It
is difficult for me to ask clients to test. But they are lazy. I asked
Observation in the IDE and SE: The time for saving in the IDE seems to
depend on the amount of time spent with the SE open and making changes. The
longer I am working with the SE, the slower saving tends be.
New observation with the "quit" command: Now, being in the IDE, saying this
and also testing, when I "quit" then interestingly enough this takes up to
30 seconds, never less than 15 seconds. Why is the blue Windows system
wheel rotating for such a long time when force-quitting? When I force
quit from the Windows Task Manager then there is no such delay.
Maybe the saving & quitting problem actually is with the quit command?
Could that be? I never thought about this before. Quitting without saving
and locked messages should be an almost instantaneous quit.
I can not check the result of the "quit" command. Whatever line of script
comes after the quit is no longer recognized.
-- Start of Quote:
When the engine saves a stackfile when it has previously been saved to
the same place...
It first moves the existing file at <filename> to <filename>~. If this
step fails (e.g. because it can't move the file) then the save command
stops and returns an error indicating that in 'the result'.
Next it attempts to save the stackfile to <filename>.
If there is an error whilst writing the stackfile then the save command
stops, deletes the partially written stackfile at <filename>, moves the
<filename>~ back to <filename> and returns an appropriate error in 'the
If the engine crashes during saving, you will be left with a partially
written <filename> and a copy of the stackfile as it was successfully
last saved at <filename>~. Obviously in this case the engine has
crashed, so there is no 'the result' to check.
If saving successfully completes, then the engine deletes <filename>~
and returns empty in 'the result'.
So - assuming the engine isn't crashing (although the long save time
sounds odd - if you can submit a report/send a stackfile which takes
ages to re-save we can take a look!), then you should be able to find
out why the save is failing, or not happening as expected by checking
'the result' after the save command which is initiating the save.
Hope this helps!
-- End of Quote
More information about the Use-livecode