Quit Command corrupts standalone (stack called by standalone splash)

classic Classic list List threaded Threaded
6 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
 // Quit Command corrupts standalone (stack called by standalone splash)
Using Indy 8.1.9 desktop standalone without encryption (same problem with
earlier versions and community version), Windows 7, 8, 10, different
machines and different users of a large company. //

Before filing a bug report or sending a help request, maybe there is a help
here...

This is an urgent question as it is highly critical for the in-house
distribution of this LiveCode application to the sales team of a large
company right now.

I can not really reproduce the problem using my own machine, but it
happened on my machine, on other peoples machines, more or less often.

I developed the app using the splash stack method (small login stack that
is made to be a standalone and actual application stack in a subfolder
called). It works. At least for all users when opening the first time.

Problems appear when opening the app through the splash screen login stack
a second time after quitting. The compiled LiveCode engine of the splash
stack often enough cannot find the application stack any longer because it
is corrupted.

Analyzing the situation, I think, it seems to be a problem quitting the
standalone app resulting in a corrupt application stack (the splash screen
standalone is not affected).

In case of corruption of the application stack, I then find two visible
files in the subfolder with the original filename of the application stack,
one shows a tilde "̃̃˜" at the end of the filename (an indication of
corruption).

Currently, I do not know how to generate a detailed error report for such
standalone. I have a friend who experiences this problem each time, and
each time he wants to use my app, he then takes a fresh copy that is good
only for a 1-time-usage ))).

The quit command is sent from the application stack.

Here are the handlers in the application stack:

on closeStack
    saveAndQuit
    pass closeStack /* goes to splash stack, engine ... tested with and
without. */
end closeStack

command saveAndQuit
   lock cursor /* Tested with and without locking and showing cursor */
   set the cursor to watch
   save this stack /* auto save, takes a long time, between 10-30 secs */
   wait 100 milliseconds with messages /* does it help? Probably not. */
   unlock cursor /* Testing with or without*/
   lock messages /* Force quit. Tested with and without. */
   quit /* Should quit safely and not corrupt the stack, but stack
sometimes is corrupted */
end saveAndQuit


Any suggestions I highly appreciated.

Thanks to all
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.

The "~" file is the original  (uncorrupted, unsaved) version of your stack
before LC executed your Save cmd. If you remove the "~" from the filename,
you'll probably find you can open that. LC creates the "~" file at the start
of the save operation and, if all goes well, removes that file when save is
complete.

My guess is your problem is rooted in the lengthy save time in the quit
routine. Here are a couple ideas of how you could deal with that:

1) Do the save within a try/catch statement so you can deal with any error.

2) If you are just saving some user data like prefs or fairly minor stuff,
then why not save that into a separate substack outside of your main
application stack? That should greatly shorten the time it takes to save.

Hope that helps.

Tom Bodine



--
Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

_______________________________________________
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
Roland,

I believe Tom is exactly right. I would restructure your two closing
handlers like this:


local sMyFilename

on closeStack
     put the filename of me into sMyFilename
     saveMe
     send "quitMe" in 1 second
end closeStack


command saveMe
    lock cursor /* Tested with and without locking and showing cursor */
    set the cursor to watch
    save this stack /* auto save, takes a long time, between 10-30 secs */
end saveMe


command quitMe
    if there is a file sMyFilename then
       unlock cursor
       lock messages
       quit
    else
       send "quitMe" to me in 0.5 seconds -- or in your preferred time
    end if
end quitMe


The above was not tested but it should solve the problem.

HTH -
Phil Davis



On 2/23/18 3:20 PM, tbodine via use-livecode wrote:

> Hi Roland.
>
> The "~" file is the original  (uncorrupted, unsaved) version of your stack
> before LC executed your Save cmd. If you remove the "~" from the filename,
> you'll probably find you can open that. LC creates the "~" file at the start
> of the save operation and, if all goes well, removes that file when save is
> complete.
>
> My guess is your problem is rooted in the lengthy save time in the quit
> routine. Here are a couple ideas of how you could deal with that:
>
> 1) Do the save within a try/catch statement so you can deal with any error.
>
> 2) If you are just saving some user data like prefs or fairly minor stuff,
> then why not save that into a separate substack outside of your main
> application stack? That should greatly shorten the time it takes to save.
>
> Hope that helps.
>
> Tom Bodine
>
>
>
> --
> Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>
> _______________________________________________
> 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
Let me improve this a bit.


On 2/23/18 4:19 PM, Phil Davis via use-livecode wrote:

> Roland,
>
> I believe Tom is exactly right. I would restructure your two closing
> handlers like this:
>
>
> local sMyFilename
>
> on closeStack
>     put the filename of me into sMyFilename
>     saveMe
>     send "quitMe" in 1 second
> end closeStack

on closeStack
     put the filename of me into sMyFilename
     send "quitMe" to me in 1 second
     saveMe
end closeStack


"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.

Thanks -
Phil

>
>
> command saveMe
>    lock cursor /* Tested with and without locking and showing cursor */
>    set the cursor to watch
>    save this stack /* auto save, takes a long time, between 10-30 secs */
> end saveMe
>
>
> command quitMe
>    if there is a file sMyFilename then
>       unlock cursor
>       lock messages
>       quit
>    else
>       send "quitMe" to me in 0.5 seconds -- or in your preferred time
>    end if
> end quitMe
>
>
> The above was not tested but it should solve the problem.
>
> HTH -
> Phil Davis
>
>
>
> On 2/23/18 3:20 PM, tbodine via use-livecode wrote:
>> Hi Roland.
>>
>> The "~" file is the original  (uncorrupted, unsaved) version of your
>> stack
>> before LC executed your Save cmd. If you remove the "~" from the
>> filename,
>> you'll probably find you can open that. LC creates the "~" file at
>> the start
>> of the save operation and, if all goes well, removes that file when
>> save is
>> complete.
>>
>> My guess is your problem is rooted in the lengthy save time in the quit
>> routine. Here are a couple ideas of how you could deal with that:
>>
>> 1) Do the save within a try/catch statement so you can deal with any
>> error.
>>
>> 2) If you are just saving some user data like prefs or fairly minor
>> stuff,
>> then why not save that into a separate substack outside of your main
>> application stack? That should greatly shorten the time it takes to
>> save.
>>
>> Hope that helps.
>>
>> Tom Bodine
>>
>>
>>
>> --
>> Sent from:
>> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>>
>> _______________________________________________
>> 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
I save all my stacks on closeTack, that is until I ran into problems with Windows sandboxing in a standalone. I had to conditionally save stacks only if I was in development.

Bob S


> On Feb 23, 2018, at 15:20 , tbodine via use-livecode <[hidden email]> wrote:
>
> Hi Roland.
>
> The "~" file is the original  (uncorrupted, unsaved) version of your stack
> before LC executed your Save cmd. If you remove the "~" from the filename,
> you'll probably find you can open that. LC creates the "~" file at the start
> of the save operation and, if all goes well, removes that file when save is
> complete.
>
> My guess is your problem is rooted in the lengthy save time in the quit
> routine. Here are a couple ideas of how you could deal with that:
>
> 1) Do the save within a try/catch statement so you can deal with any error.
>
> 2) If you are just saving some user data like prefs or fairly minor stuff,
> then why not save that into a separate substack outside of your main
> application stack? That should greatly shorten the time it takes to save.
>
> Hope that helps.
>
> Tom Bodine


_______________________________________________
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
What about using shutDownRequest? If you don’t pass it, it prevents the quit from happening.

Marty

> Let me improve this a bit.
>
>
> On 2/23/18 4:19 PM, Phil Davis via use-livecode wrote:
>> Roland,
>>
>> I believe Tom is exactly right. I would restructure your two closing handlers like this:
>>
>>
>> local sMyFilename
>>
>> on closeStack
>>     put the filename of me into sMyFilename
>>     saveMe
>>     send "quitMe" in 1 second
>> end closeStack
>
> on closeStack
>     put the filename of me into sMyFilename
>     send "quitMe" to me in 1 second
>     saveMe
> end closeStack
>
>
> "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.
>
> Thanks -
> Phil
>
>>
>>
>> command saveMe
>>    lock cursor /* Tested with and without locking and showing cursor */
>>    set the cursor to watch
>>    save this stack /* auto save, takes a long time, between 10-30 secs */
>> end saveMe
>>
>>
>> command quitMe
>>    if there is a file sMyFilename then
>>       unlock cursor
>>       lock messages
>>       quit
>>    else
>>       send "quitMe" to me in 0.5 seconds -- or in your preferred time
>>    end if
>> end quitMe
>>
>>
>> The above was not tested but it should solve the problem.
>>
>> HTH -
>> Phil Davis
>>
>>
>>
>> On 2/23/18 3:20 PM, tbodine via use-livecode wrote:
>>> Hi Roland.
>>>
>>> The "~" file is the original  (uncorrupted, unsaved) version of your stack
>>> before LC executed your Save cmd. If you remove the "~" from the filename,
>>> you'll probably find you can open that. LC creates the "~" file at the start
>>> of the save operation and, if all goes well, removes that file when save is
>>> complete.
>>>
>>> My guess is your problem is rooted in the lengthy save time in the quit
>>> routine. Here are a couple ideas of how you could deal with that:
>>>
>>> 1) Do the save within a try/catch statement so you can deal with any error.
>>>
>>> 2) If you are just saving some user data like prefs or fairly minor stuff,
>>> then why not save that into a separate substack outside of your main
>>> application stack? That should greatly shorten the time it takes to save.
>>>
>>> Hope that helps.
>>>
>>> Tom Bodine
>>>
>>>
>>>
>>> --
>>> Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>>>
>>> _______________________________________________
>>> 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


_______________________________________________
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