Quit Command corrupts standalone (stack called by standalone splash)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
Thanks, Phil and Tom

I already replied, but I cannot see my first reply to your answers.

Did it appear in the list?


Phil:
>> "quitMe" should be sent before 'saveMe' is executed, because the 'save'
command is blocking. It would prevent 'quitMe' from being sent until (in
this case) 1 second after 'saveMe' has finished.

Well, it is blocking. Issuing "quit" just quits if messages are locked.So,
to quit before save would require not to force a quit. Right? I will test.

The main problem is that the IDE is ok, even though saving takes a long
time, but no errors I can see. The standalones are the culprit, and I have
limited to access to other peoples computers using my standalones. And on
my machine the problem does not appear regularly.

// I hope this message appears, otherwise I will have to check what is
wrong sending messages to the list. //

Thanks
Roland
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
Hi Roland,

This is the only reply of yours that I see.


On 2/26/18 4:13 AM, R.H. via use-livecode wrote:

> Thanks, Phil and Tom
>
> I already replied, but I cannot see my first reply to your answers.
>
> Did it appear in the list?
>
>
> Phil:
>>> "quitMe" should be sent before 'saveMe' is executed, because the 'save'
> command is blocking. It would prevent 'quitMe' from being sent until (in
> this case) 1 second after 'saveMe' has finished.
>
> Well, it is blocking. Issuing "quit" just quits if messages are locked.So,
> to quit before save would require not to force a quit. Right? I will test.

You're right, but that's not what my code does. It sends 'quitMe' (which
contains the 'quit') 1 second after 'saveMe' has started. As you may
know, 'send in x seconds' adds 'quitMe' to the pendingMessages queue, so
it will execute as soon as the designated time has passed AND no other
handler is running.

For what it's worth, the correction I made to my own code is still not
correct. The whole thing should look like this:


local sMyTildeFilename

on closeStack
     -- create a path to the 'tilde' file (which doesn't yet exist)
     put (the filename of me & "~") into sMyTildeFilename

     -- add 'quitMe' to the pendingMessages
     send "quitMe" in 1 second

     -- save this stack
     saveMe
end closeStack


command saveMe
    lock cursor
    set the cursor to watch
    save me -- creates the tilde file at beginning, deletes it at end
end saveMe


command quitMe
    -- wait until tilde file is gone, then quit
    if there is a file sMyTildeFilename -- 'save' has not completed yet
    then -- try again later
        send "quitMe" to me in 0.5 seconds
    else
        unlock cursor
        lock messages
        quit
    end if
end quitMe



Phil

>
> The main problem is that the IDE is ok, even though saving takes a long
> time, but no errors I can see. The standalones are the culprit, and I have
> limited to access to other peoples computers using my standalones. And on
> my machine the problem does not appear regularly.
>
> // I hope this message appears, otherwise I will have to check what is
> wrong sending messages to the list. //
>
> Thanks
> Roland
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

--
Phil Davis


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
Stack file corruption is very rare with LiveCode.  It has happened now
and then, but is rare enough (and of course serious enough) to merit
attention by the LC team.

Even if we can mitigate the issue by altering your code, the main
question remains:  why does a save operation become interrupted, and is
that interruption caused by external factors or from an internal bug?

Unless you know the cause of the corruption (failing hard drive, flaky
network with mounted network drive, use of Dropbox or other synced
folder with unpredictable behavior, etc.) it may be helpful opening a
bug report if only to allow the team to investigate the corrupted file
to see if it brings their attention to something internal which may need
refinement.

--
  Richard Gaskin
  Fourth World Systems

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
Richard, could you elaborate on the issues with Dropbox? Is there a recommended procedure for dealing with it?

Marty

On Feb 26, 2018, at 11:07 AM, Richard Gaskin via use-livecode <[hidden email]> wrote:

> Stack file corruption is very rare with LiveCode.  It has happened now and then, but is rare enough (and of course serious enough) to merit attention by the LC team.
>
> Even if we can mitigate the issue by altering your code, the main question remains:  why does a save operation become interrupted, and is that interruption caused by external factors or from an internal bug?
>
> Unless you know the cause of the corruption (failing hard drive, flaky network with mounted network drive, use of Dropbox or other synced folder with unpredictable behavior, etc.) it may be helpful opening a bug report if only to allow the team to investigate the corrupted file to see if it brings their attention to something internal which may need refinement.
>
> --
> Richard Gaskin
> Fourth World Systems
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
Knapp Martin wrote:

 > Richard, could you elaborate on the issues with Dropbox?

I first came across it in a search at Google for "dropbox sqlite",
looking for tips on making the most of that relationship.  What I found
was a long series of support forum and blog posts filled with horror
stories of out of sync or corrupted DB files.

Some merely lose a record.  Others lose the DB.  And so many have no
problem at all that it seems like something we should all be doing,
until you look into it far enough to find those who've lost records or
the entire DB.

Of all the things I've read, this forum post covered more ground more
succinctly than most:

----
    tl;dr: Dropbox fails the ACID test for databases.  So does its
    competitor Box, which works the same way.  Use it for SQLite
    databases only if your transfer time exceeds its synch time.

    <https://en.wikipedia.org/wiki/ACID>

    Dropbox does not share files across the internet.  It copies
    changed files from one computer to its server, then from that
    server to all the other computers which have access to that
    shared folder.

    Dropbox copies an entire file every time a part of it is updated.
    If you have a 200GB database and delete one row, it needs to copy
    the entire database file to all the other computers that can
    access it.  While that works fine for small files, it will involve
    a lot of traffic as your files grow in size.

    If two copies of the file are updated at the same time on different
    computers, the changes made in one copy disappear.  Your
    user-interface will ask you which one you want, but you may not
    have enough knowledge to pick the 'best' one.

    If Dropbox decides to take a copy while SQLite is in the middle
    of processing a transaction, you will temporarily have a copy of
    the database with a partially-processed transaction on all the
    computers which have access to that shared area.

    Dropbox doesn’t understand that the database file and the journal
    file go together, even if they’re in the same folder.  And in order
    to stop one user from hogging its servers there’s sometimes a short
    delay between when it updates its copy of one file and when it
    updates its copy of another file.  So it’s possible for one computer
    which has a copy of the database to have a newer database file than
    its journal file, or vice versa.

    SQLite autorepairs files when it finds a database file and a journal
    file which don’t match.  I don’t know what it would do under the
    above two conditions.  And what it would do would vary depending on
    which file Dropbox decided to copy first.

    Given all the above, I might use Dropbox or Box to promulgate copies
    of a SQLite database, but only if
    (A) I had an backup of a recent version and the backup system does
    not involve Dropbox/Box.
    (B) If I was fairly sure that if I used one computer to update the
    database, none of the other computers would try to open the file
    (even just for reading) until a couple of minutes after the updates
    were done and the service had had time to sync both database and
    journal file.
----
http://sqlite.1065341.n5.nabble.com/Sqlite-Dropbox-tp95173p95177.html



 > Is there a recommended procedure for dealing with it?

This vendor who uses SQLite for their data storage has the simplest
solution for sharing their files via Dropbox:  Don't do it. ;)  At
least, not directly, but this isn't going to work for so many users who
don't spend much time monkeying with files directly:

https://www.maxqda.com/faq/a-13-can-i-store-my-maxqda-projects-in-cloud-based-services-like-dropbox


If the SQlite + Dropbox combo were super-robust we wouldn't see so many
purpose-built sync systems out there.  Sync systems aren't fun to write
and eat a lot of time, so if devs could avoid it so simply they would.

But they don't.  So many proprietary syncs out there, almost a new one
for every app that syncs.

And if you look into sync, you find just about every app that came up
with a syncing method has a very long blog post about their sync 2.0,
needed after whatever they came up with when they got started didn't
work out.

Every OS vendor has a sync system in their APIs, but for obvious lock-in
reasons none of them are compatible with any other.

So it's left up to us to figure this stuff out, a million developers all
repeating the same wheel-building exercises of Evernote and every other
sync-based system....

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
Thanks for the in-depth reply. Are there known issues with saving LC stacks to Dropbox? I was thinking of Roland's issue with corruption and Phil's suggested fix of watching the file with the tilde character before allowing a quit to complete. I have an app where users create documents (stacks) and saving them to Dropbox is a built-in option. I have one customer who stores their stacks on a network server and a few times they've ended up with a corrupted stack. These stacks are 1-2 mb in size, so nothing huge, but they are of critical importance. I don’t know of anyone having trouble with Dropbox specifically, but if I can do something to make the process more robust, then that would be of great interest.

Marty

> Knapp Martin wrote:
>
> > Richard, could you elaborate on the issues with Dropbox?
>
> I first came across it in a search at Google for "dropbox sqlite", looking for tips on making the most of that relationship.  What I found was a long series of support forum and blog posts filled with horror stories of out of sync or corrupted DB files.
>
> Some merely lose a record.  Others lose the DB.  And so many have no problem at all that it seems like something we should all be doing, until you look into it far enough to find those who've lost records or the entire DB.
>
> Of all the things I've read, this forum post covered more ground more succinctly than most:
>
> ----
>   tl;dr: Dropbox fails the ACID test for databases.  So does its
>   competitor Box, which works the same way.  Use it for SQLite
>   databases only if your transfer time exceeds its synch time.
>
>   <https://en.wikipedia.org/wiki/ACID>
>
>   Dropbox does not share files across the internet.  It copies
>   changed files from one computer to its server, then from that
>   server to all the other computers which have access to that
>   shared folder.
>
>   Dropbox copies an entire file every time a part of it is updated.
>   If you have a 200GB database and delete one row, it needs to copy
>   the entire database file to all the other computers that can
>   access it.  While that works fine for small files, it will involve
>   a lot of traffic as your files grow in size.
>
>   If two copies of the file are updated at the same time on different
>   computers, the changes made in one copy disappear.  Your
>   user-interface will ask you which one you want, but you may not
>   have enough knowledge to pick the 'best' one.
>
>   If Dropbox decides to take a copy while SQLite is in the middle
>   of processing a transaction, you will temporarily have a copy of
>   the database with a partially-processed transaction on all the
>   computers which have access to that shared area.
>
>   Dropbox doesn’t understand that the database file and the journal
>   file go together, even if they’re in the same folder.  And in order
>   to stop one user from hogging its servers there’s sometimes a short
>   delay between when it updates its copy of one file and when it
>   updates its copy of another file.  So it’s possible for one computer
>   which has a copy of the database to have a newer database file than
>   its journal file, or vice versa.
>
>   SQLite autorepairs files when it finds a database file and a journal
>   file which don’t match.  I don’t know what it would do under the
>   above two conditions.  And what it would do would vary depending on
>   which file Dropbox decided to copy first.
>
>   Given all the above, I might use Dropbox or Box to promulgate copies
>   of a SQLite database, but only if
>   (A) I had an backup of a recent version and the backup system does
>   not involve Dropbox/Box.
>   (B) If I was fairly sure that if I used one computer to update the
>   database, none of the other computers would try to open the file
>   (even just for reading) until a couple of minutes after the updates
>   were done and the service had had time to sync both database and
>   journal file.
> ----
> http://sqlite.1065341.n5.nabble.com/Sqlite-Dropbox-tp95173p95177.html
>
>
>
> > Is there a recommended procedure for dealing with it?
>
> This vendor who uses SQLite for their data storage has the simplest solution for sharing their files via Dropbox:  Don't do it. ;)  At least, not directly, but this isn't going to work for so many users who don't spend much time monkeying with files directly:
>
> https://www.maxqda.com/faq/a-13-can-i-store-my-maxqda-projects-in-cloud-based-services-like-dropbox
>
>
> If the SQlite + Dropbox combo were super-robust we wouldn't see so many purpose-built sync systems out there.  Sync systems aren't fun to write and eat a lot of time, so if devs could avoid it so simply they would.
>
> But they don't.  So many proprietary syncs out there, almost a new one for every app that syncs.
>
> And if you look into sync, you find just about every app that came up with a syncing method has a very long blog post about their sync 2.0, needed after whatever they came up with when they got started didn't work out.
>
> Every OS vendor has a sync system in their APIs, but for obvious lock-in reasons none of them are compatible with any other.
>
> So it's left up to us to figure this stuff out, a million developers all repeating the same wheel-building exercises of Evernote and every other sync-based system....
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
On 02/26/2018 05:14 PM, Richard Gaskin via use-livecode wrote:
> Knapp Martin wrote:
>
>  > Richard, could you elaborate on the issues with Dropbox?
>
> I first came across it in a search at Google for "dropbox sqlite",
> looking for tips on making the most of that relationship.  What I found
> was a long series of support forum and blog posts filled with horror
> stories of out of sync or corrupted DB files.

To counteract some of the FUD, storing a large multiuser database in the
cloud with long sync times and no proper locking is just a bad idea in
the first place. But unless you've got a particularly huge LiveCode
stack, you're not going to see this kind of syncing problem. And
typically a Dropbox folder is confined to one user, even if it's
replicated on multiple machines, so you're not going to run into
multiuser issues. I have quite a lot of files stored on Dropbox, but
they're fairly small so the update sync time is very fast. And if the
sync fails because of network issues, the cloud copy isn't updated. But
I wouldn't put a database on Dropbox precisely because of the problems
listed in that article.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
Knapp Martin wrote:

 > Thanks for the in-depth reply. Are there known issues with saving LC
 > stacks to Dropbox? I was thinking of Roland's issue with corruption
 > and Phil's suggested fix of watching the file with the tilde character
 > before allowing a quit to complete. I have an app where users create
 > documents (stacks) and saving them to Dropbox is a built-in option.

My hunch (read, "I'm likely wrong, wait for something more definitive
from someone on the core team or Brian Milby, since he reads the engine
source <g>) is that LC files are less prone to a wide range of
disk-related issues by virtue of being written in a single pass.

HyperCard, FileMaker, SQLite, and others are read and written in pages,
which works more reliably in some (SQLite) than others (no one misses
HC's 504 errors <g>).  Moving stuff in and out of portions of a file
that may not change much otherwise isn't necessarily brittle in itself
(SQLite as a reputation for being enormously robust), but we can
envision how larger SQLite files may confuse a syncing system that can
only move chunks of data over a network so quickly.

Since LC files are, near as I recall, written fresh from beginning to
end with each save command, the result is usually a cleaner file than
with some paging systems.

And it's also faster to write everything in one pass than writing the
same amount of data by moving back and forth throughout a file, so my
hunch would be that LC stack files would likely be less prone to error
when synced over Dropbox than SQLite files.

But by no means should this be taken as gospel, and certainly not as any
indication that we should drop SQLite and use stack files instead.
Different formats for different purposes.

And as Mark Wieder noted, some of the biggest challenges with syncing
occur with multiple users accessing a given resource simultaneously.

Those are very real challenges, which may be why so many developers over
the years keep writing their own sync mechanisms, with no single
solution having emerged as the one-size-fits-all answer.

Consider this scenario with stack files, for example:

Mark writes a stack, then I open it, then you open it.  You and I are
both making changes, and I save mine a few seconds before you save
yours. In that scenario, what's on disk?

When I get back to work on the file tomorrow, I'll likely be
disappointed to find that everything I'd done is now gone.  I can see
only your changes, since yours were the last saved and when you saved
you hadn't yet updated to have a copy with my changes.  So after Dropbox
faithfully performs everything we ask it to do, my changes are gone forever.

Write-locking can help with things like that, and that's a subject in
itself.  At what level of granularity should we lock?  And before
editing begins do we first compare what's in memory with what's in the
data store to ensure what we're about to edit is the most recent copy?
How do we handle conflicts, when one inevitably occurs?

So many ways to handle sync....

 > I have one customer who stores their stacks on a network server and
 > a few times they've ended up with a corrupted stack.

Corruption is very interesting to me.  Lost data is usually explainable
through simple multiuser workflow weaknesses, such as inadequate locking
mechanisms.  But corruption in LC means something interrupted the write,
or overwrote portions before the write was completed.  And since LC
stacks files are written in a single pass, whatever caused it to corrupt
was very efficient at it, as it had little time to do it in.

I can conceive of a possible scenario in which neither Dropbox nor LC
has a bug per se at all, but which may account for corruption:

1. Your app issues a save command on a large stack.
2. Dropbox begins syncing the file to the server.
3. Your friend has the same file open on his machine.
4. On his machine, Dropbox notices the server has a newer version, and
prepares to update his copy.
5. He starts a save in his stack.
6. Dropbox has written a portion of the stack from the server to his
disk, but stopped when it noticed the file was being updated.
7. After your friend's save is done, the corrupted stack is then copied
to the server, where it later propagates to your machine.
RESULT: everyone now has the same file, and it's broken.

I haven't studied the file system triggers and server monitoring that
trigger reads and writes in Dropbox.  And if it's proprietary, chances
are no one outside that company has either.

There are many ways that imagined scenario might for all I know be
accounted for in the way Dropbox is written.  But there may also be
other scenarios that can produce the same corrupted result that I
haven't thought of.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
On 02/26/2018 07:38 PM, Richard Gaskin via use-livecode wrote:

> Consider this scenario with stack files, for example:
>
> Mark writes a stack, then I open it, then you open it.  You and I are
> both making changes, and I save mine a few seconds before you save
> yours. In that scenario, what's on disk?

Keep in mind the Dropbox and Box are primarily single-user storage
applications. I can, for instance, give read access to others, and if
I'm feeling wild and crazy I can even give write access, but I have to
go out of my way to do this. Normally I'm the only one who can write or
even read the files in my folder, even though they're synced to multiple
machines under my control.

> Corruption is very interesting to me.  Lost data is usually explainable
> through simple multiuser workflow weaknesses, such as inadequate locking
> mechanisms.  But corruption in LC means something interrupted the write,
> or overwrote portions before the write was completed.  And since LC
> stacks files are written in a single pass, whatever caused it to corrupt
> was very efficient at it, as it had little time to do it in.

I *have* had corrupted LiveCode stacks before, and I can count them on
two fingers of one hand. One of them was actually sitting in my Dropbox
folder, so who knows what happened to it? But my favorite thing about
Dropbox is that it stores earlier versions of your files, so I just
reverted to an earlier copy of that stack and carried on.

--
  Mark Wieder
  [hidden email]



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
On February 26, 2018 9:40:58 PM Richard Gaskin via use-livecode
<[hidden email]> wrote:

> There are many ways that imagined scenario might for all I know be
> accounted for in the way Dropbox is written.  But there may also be
> other scenarios that can produce the same corrupted result that I
> haven't thought of.

Just so Marty won't worry too much, Dropbox handles file conflicts:
https://www.dropbox.com/help/syncing-uploads/conflicted-copy

"If two people change the same file at the same time, Dropbox won't try to
merge the changes. Instead, it will save the original file as well as a
second version which has the same name but is appended with "conflicted
copy," the name of the person or computer responsible, and the date the
conflict occurred. By creating a conflicted file, Dropbox ensures that all
changes are preserved and nobody will overwrite another person's hard work."

I've seen this happen. It's a pain trying to merge the changes if there are
too many but nothing gets lost.

I've seen the occasional corrupted LC stack, most recently just last night,
but it was an extreme edge case no one else is likely to encounter and I
think I know what happened. The solution was "don't do that."

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
Hi Richard and all contributing...

Thanks a lot for all answer...)))

I have received the corrupted files from clients (original stack that is
split into two files during save I guess) and will prepare a bug report
attaching them together with the original stack.

It is very difficult to know about which machines are creating the problem.
Definitely, it happens on other peoples machines using Windows 7 and 10,
and it happened before on my own.

The standalone will start showing strange behaviors especially when the
user clicks the standard Windows close button on the upper left corner.
That should usually invoke the "closeStack" handler. Using my own "Quit"
menu seems to be safer. Using try and catch and various ways of quitting
and saving did not make any difference. The error message using "catch" in
the "try" statement should have been written to a separate file on the
client's machine, but it did not even create a file. In the IDE there are
no errors visible.

What happens is that on the user's machine the blueish mouse wheel is
turning and then there is no longer any mouse action even on the Desktop
and the window turns white and the app becomes non-responsive. After a
while, about 30 seconds to 1 minute, the app disappears and also there is
no longer any process visible.

I will once again try sending a copy without any "save" and just a forced
quit and see what happens. Then user would have to save manually before
closing -- if that could be a reason for the corrupted file.

This is using Indy 8.1.9 but happened in earlier versions as well.

Roland
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Quit Command corrupts standalone (stack called by standalone splash)

J. Landman Gay via use-livecode
On 2/27/18 9:40 AM, R.H. via use-livecode wrote:
> The standalone will start showing strange behaviors especially when the
> user clicks the standard Windows close button on the upper left corner.
> That should usually invoke the "closeStack" handler.

I'd submit a bug report for this, but as a workaround, try a
closeStackRequest handler to save the stack. This message happens before
closeStack is sent, and may be a safer way to manage the file.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode