Sorry, I must send a correction, I meant MegaBytes, not Giga Bytes (typing too fast)...
This is sentence needs correction: "The size of the stack file is nearly 4 MB, probably mainly because of some technical images." Regards Roland ---------- Forwarded message --------- From: R.H. <roland.huettm...@gmail.com> Date: Sa., 19. Jan. 2019 um 13:56 Uhr Subject: Re: windows defender issues? & other AV To: LiveCode Runrev.Com <use-livecode@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 already. 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. Kind regards Roland -- 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 result'. 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! Warmest Regards, Mark. -- End of Quote _______________________________________________ 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
