The user isn't asking for a way to quit, just for a controlled exit.
Typically this is done from the entry screen (the Home stack in this case)
when the Back button is pressed. Right now the app says "you are home" and
blocks the backKey message. Instead, ask if they want to quit and if so,
pas
Sannyasin Brahmanathaswami wrote:
> I have two requests that there be way to quit the app.
Few apps have that. Why do those users want this?
> I may not have got that right… or maybe there are nuances about the
> way Android works. Can you remind to Best Practice?
Mobile OSes present a very
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
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
> wrote:
>
> Hi Roland.
>
> The "~" file is the origi
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 workar
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 abou
On February 26, 2018 9:40:58 PM Richard Gaskin via use-livecode
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.
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
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
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
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)
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
storie
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
wrote:
> Stack file corruption is very rare with LiveCode. It has happened now and
> then, but is rare enough (a
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 interrupte
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 th
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
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 lock
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 fi
In my case, my second stack *was* a substack and quit still didn't work.
On Wed, Nov 11, 2015 at 9:42 PM, J. Landman Gay
wrote:
> That's what I suspected; the stacks aren't actually substacks. Now it
> makes sense. Thanks for the clarification.
>
> On 11/11/2015 10:59 PM, Howard Bornstein wrote:
That's what I suspected; the stacks aren't actually substacks. Now it
makes sense. Thanks for the clarification.
On 11/11/2015 10:59 PM, Howard Bornstein wrote:
The dictionary says this (from LC 6.7.5):
In standalones, some care is needed to ensure you receive the
*shutdownRequest* message if
The dictionary says this (from LC 6.7.5):
In standalones, some care is needed to ensure you receive the
*shutdownRequest* message if your application uses multiple stacks. The
most reliable approach is to install a library stack or backscript to
handle the message when your application starts up.
On 11/11/2015 7:54 PM, Mark Smith wrote:
is it not the case that the message path goes from substacks
to the main stack? If so, should not a "shutdownRequest" message not handled
in a sub stack be passed up the message path to the main stack? In which
case you don't need shutdownRequests in each
I am just coming back to LC after a few months off (18 perhaps?) so I am a
bit rusty but is it not the case that the message path goes from substacks
to the main stack? If so, should not a "shutdownRequest" message not handled
in a sub stack be passed up the message path to the main stack? In which
I've updated the bug report with Martin's solution in case anyone else runs
into this.
On Thu, Nov 5, 2015 at 5:20 AM, paolo mazza
wrote:
> Nearly 1 year ago I posted this
> http://quality.runrev.com/show_bug.cgi?id=14263 .
> It was confirmed but probably it has not been fixed yet.
> All the be
Nearly 1 year ago I posted this
http://quality.runrev.com/show_bug.cgi?id=14263 .
It was confirmed but probably it has not been fixed yet.
All the best,
Paolo
On Thu, Nov 5, 2015 at 4:47 AM, Howard Bornstein wrote:
> This really helped me out. Thanks Martin! I couldn't get my standalone to
> qui
This really helped me out. Thanks Martin! I couldn't get my standalone to
quit no matter what. This did the trick.
On Tue, Nov 26, 2013 at 10:19 AM, Martin Koob wrote:
> Hi
>
> It has been a long time since I set this up in my application so I don't
> remember exactly the logic as to why I set t
On 12/17/2012 05:21 PM, Bernard Devlin wrote:
I don't know why you are seeing the light show. But could you not set the
visible of those stacks to false in a shutdown/shutdownRequest handler?
Obviously, you'd have to change that property when the stacks are loaded
again.
Thanks; that should do
I don't know why you are seeing the light show. But could you not set the
visible of those stacks to false in a shutdown/shutdownRequest handler?
Obviously, you'd have to change that property when the stacks are loaded
again.
Bernard
On Sun, Dec 16, 2012 at 12:37 PM, Richmond wrote:
> So, a be
On Oct 1, 2011, at 12:07 PM, Charles Szasz wrote:
> In the Menu Builder, I have always set Quit for the Mac with the Mnemonic
> checked and set to Q alone with the Shortcut set to Command. I frequently
> use a Quit button in my apps which the user could quit an app.
>
> I just noticed a few
On Sat, Oct 1, 2011 at 1:07 PM, Charles Szasz wrote:
> In the Menu Builder, I have always set Quit for the Mac with the Mnemonic
> checked and set to Q alone with the Shortcut set to Command. I frequently
> use a Quit button in my apps which the user could quit an app.
>
> I just noticed a few da
On Jan 9, 2011, at 7:40 AM, Richmond wrote:
I want to disable the ability of Mac users to QUIT
by pressing Command-Q; tis is to force them to
use localised QUIT buttons (each with slightly
different characteristics) on cards within a stack.
This is in my saved tidbits stack, from a discussion
Hi Jaqueline and Richmond,
> On 1/9/11 6:40 AM, Richmond wrote:
>> I want to disable the ability of Mac users to QUIT
>> by pressing Command-Q; tis is to force them to
>> use localised QUIT buttons (each with slightly
>> different characteristics) on cards within a stack.
>
> Try trapping the shu
On 1/9/11 6:40 AM, Richmond wrote:
I want to disable the ability of Mac users to QUIT
by pressing Command-Q; tis is to force them to
use localised QUIT buttons (each with slightly
different characteristics) on cards within a stack.
Try trapping the shutdownrequest message.
--
Jacqueline Landma
33 matches
Mail list logo
