updating progress to user during long handler

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

updating progress to user during long handler

jameshale
I have a splash stack that loads and calls the main stack before closing.
While the splash is being displayed the preopen handler in my main stack asks for a file to locate.
Once located it then loads and processes the file before it takes over.

The processing takes some time and I have been trying to work out a way of informing the user of what it taking place.
I have a field on the splash stack which contains info text for the user and I would like to change this text as the processing is going on.

I thought I could use something like this...

    put "Extracting epub...." into mupdate
    send "updateme mupdate" to stack "splash"
    wait 0 milliseconds with messages

at different places within the processing handler and it would send the text off an update the splash stack field.
(updateme is a handler in the splash stack script which simply enters "mupdate" into the field.)

Obviously this doesn't work.

First, can I do what I want?
Second, where am I going wrong?

Any help would be appreciated.


James






_______________________________________________
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: updating progress to user during long handler

dunbarxx
Hi.


While you have your processing handler doing its thing, why not increment a progress bar at intervals? I do not know if that process knows accurately where it is along its journey, but this is the best feedback for the user.


I have noticed progress bars that proceed nicely, giving the user hope for a speedy finish, and then "hang" 99% of the way through for a while. That is why I asked if your process "knows" its place.


Craig Newman



-----Original Message-----
From: James Hale <[hidden email]>
To: use-livecode <[hidden email]>
Sent: Tue, Feb 23, 2016 9:25 am
Subject: updating progress to user during long handler

I have a splash stack that loads and calls the main stack before closing.
While the splash is being displayed the preopen handler in my main stack asks for a file to locate.
Once located it then loads and processes the file before it takes over.

The processing takes some time and I have been trying to work out a way of informing the user of what it taking place.
I have a field on the splash stack which contains info text for the user and I would like to change this text as the processing is going on.

I thought I could use something like this...

    put "Extracting epub...." into mupdate
    send "updateme mupdate" to stack "splash"
    wait 0 milliseconds with messages

at different places within the processing handler and it would send the text off an update the splash stack field.
(updateme is a handler in the splash stack script which simply enters "mupdate" into the field.)

Obviously this doesn't work.

First, can I do what I want?
Second, where am I going wrong?

Any help would be appreciated.


James






_______________________________________________
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: updating progress to user during long handler

Mark Waddingham-2
In reply to this post by jameshale
On 2016-02-23 15:23, James Hale wrote:

> I thought I could use something like this...
>
>     put "Extracting epub...." into mupdate
>     send "updateme mupdate" to stack "splash"
>     wait 0 milliseconds with messages
>
> at different places within the processing handler and it would send
> the text off an update the splash stack field.
> (updateme is a handler in the splash stack script which simply enters
> "mupdate" into the field.)

As far as I can see, that should work fine - the screen is updated after
every command is executed (if necessary - i.e. something has changed)
unless the commands are executed inside of a lock screen...

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
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: updating progress to user during long handler

jameshale
In reply to this post by dunbarxx
Hi Craig,
This is what I initially did but, as you surmised, I actually had no way of knowing or predicting the actual progress. I then made some calculations and 'step' loops placing a sequence of progress bar updates.
Didn't work. Some bars didn't show and those that did didn't progress.
Hence I thought of the simpler solution of just informing the user of what is going on.
Reply | Threaded
Open this post in threaded view
|

Re: updating progress to user during long handler

jameshale
In reply to this post by Mark Waddingham-2
Hi Mark,

Hmm, it is possible I have a lock screen buried in there somewhere.
I will check it out.
Good to know the code should work.
Reply | Threaded
Open this post in threaded view
|

Re: updating progress to user during long handler

jameshale
In reply to this post by jameshale
Ok, so no lockscreens anywhere in the routines being called from start to end.
Guess the problem lies elsewhere.
I put in a few BEEPs at each 'progressive step and they all fired ok but there was still no update to the text in my splash stack.
I am using the glx framework and it might be that it is getting in the way.
Frustrating.
_______________________________________________
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: updating progress to user during long handler

Phil Davis-5
Hi James,

I find it sometimes helps to lock & unlock the screen right after
updating a progress bar, when it's part of a long process at least. Or
throw in a "wait 0 seconds" right after it - that can help too. It seems
the OS sometimes needs a reminder that it's time for it to update the
screen.

Thanks -
Phil


On 2/23/16 7:07 PM, James Hale wrote:

> Ok, so no lockscreens anywhere in the routines being called from start to end.
> Guess the problem lies elsewhere.
> I put in a few BEEPs at each 'progressive step and they all fired ok but there was still no update to the text in my splash stack.
> I am using the glx framework and it might be that it is getting in the way.
> Frustrating.
> _______________________________________________
> 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: updating progress to user during long handler

jameshale
Thanks for the thought Phil
     
Phil Davis-5 wrote
I find it sometimes helps to lock & unlock the screen right after
......
Tried it but no change.
Reply | Threaded
Open this post in threaded view
|

Re: updating progress to user during long handler

Kay C Lan
On Wed, Feb 24, 2016 at 9:24 PM, jameshale <[hidden email]> wrote:

>
> Tried it but no change.
>

When you say you added some Beeps, was this to the mainstack handler or the
updateme handler in the splash stack? If it wasn't in the updateme what
happens if you move the beep to there?

If you put a breakpoint immediately after the line in the updateme handler
which places text into the fld, when stopped during debugging is the text
actually in the field? If you place the breakpoint in your mainstack
handler immediately after the send "updateme mupdate" when stopped is the
text in the field?

Instead of your fld, what happens if you send the text to the message box?
_______________________________________________
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: updating progress to user during long handler

jameshale
Hi Kay,
Actually never thought of that (doh!)
Beeps in the updateme handler fire. - so the handler is getting the message
Breakpoints in updateme as well as following "send" in main routine show the text appearing in the SPLASH stack.

So, the messages are being sent.
The updateme handler is being run (BEEP was sounded)
The field will update, WHEN a breakpoint is hit.
The field does not update (except for a flash just at the very end of the main handler) when no breakpoints are present.

placing the update message in the message box (put "blah blah blah") opens the message box but does NOT update it.

So from all this I can see that the messages are being passed, the screen is simply not updating.
Reply | Threaded
Open this post in threaded view
|

Re: updating progress to user during long handler

Kay C Lan
On Fri, Feb 26, 2016 at 9:56 AM, jameshale <[hidden email]> wrote:

>
> So from all this I can see that the messages are being passed, the screen
> is
> simply not updating.
>

Which of course is why everyone else responded as they did; it happens.

Now test some 'descending' wait after the text has been placed in the field:

wait 1 sec
wait 1 tick
wait 1 millisec

See if you can come to a compromise that allows the screen to refresh
without slowing the code.
_______________________________________________
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: updating progress to user during long handler

jameshale
Hi Kay,
Well way ahead there.
I had tried a one second delay before my first post.
It had no effect (except for taking longer😊)
Kay C Lan wrote
On Fri, Feb 26, 2016 at 9:56 AM, jameshale <[hidden email]> wrote:

>
> Now test some 'descending' wait after the text has been placed in the field:

wait 1 sec
wait 1 tick
wait 1 millisec

See if you can come to a compromise that allows the screen to refresh
without slowing the code.
_______________________________________________
Reply | Threaded
Open this post in threaded view
|

Re: updating progress to user during long handler

Kay C Lan
Strange.

If your mainstack handler is in preOpenStack have you tried it in
preOpenCard or vice versa?

Or try this kludge. Move your mainstack handler to 'openCard'. Change your
current preOpenStack/Card script to simply move the stack off screen,
that's it. At the end of your mainstack's new openCard handler, lockscreen,
move the mainstack to on screen, unlock screen.

Hopefully then at the end of the preOpenStack/Card script the screen will
unlock, your openCard handler will send your updateme handler and the
screen will update as you proceed.
_______________________________________________
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: updating progress to user during long handler

Richard Gaskin
In reply to this post by jameshale
jameshale wrote:

 > Kay C Lan wrote
 >> Now test some 'descending' wait after the text has been placed in the
 >>> field:
 >>
 >> wait 1 sec
 >> wait 1 tick
 >> wait 1 millisec
 >>
 >> See if you can come to a compromise that allows the screen to refresh
 >> without slowing the code.
 >
 > I had tried a one second delay before my first post.
 > It had no effect (except for taking longer😊)

Is it possible that the lockScreen is being set somewhere in the scripts
running during that loop?

You might add something like "put the lockscreen" somewhere in the
middle of the code, and if it's true then you know it's set before then;
if it's false move it down further and repeat the test.

--
  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: updating progress to user during long handler

Dr. Hawkins
In reply to this post by Kay C Lan
On Thu, Feb 25, 2016 at 7:28 PM, Kay C Lan <[hidden email]> wrote:

> Now test some 'descending' wait after the text has been placed in the
> field:
>
> wait 1 sec
> wait 1 tick
> wait 1 millisec
>

What about "wait 0 with messages"?

Isn't the "with messages" necessary if you want something to happen?


--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
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: updating progress to user during long handler

jameshale
SOLVED:

Changed the updateme handler (in the splash stack) to include unlocking the screen

      on updateme para
          set lockscreen to FALSE
          put para into fld "theprogress"
      end updateme

All the progress updates now come through.

Thanks to everyone who helped get me here.


For those that came in late the issue was updating a field in a splash stack while the main stack got ready for the show.
I had placed 'progress' notes at different places in the main stack opening handlers and sent them to the splash stack for display in a text field. (Multiple handlers of varying and unpredictable lengths so progress bars not really an option.)

The snippet I used at these message points was like this:
    put "Extracting epub...." into mupdate
    send "updateme mupdate" to stack "splash"
    wait 0 milliseconds with messages

Where the updateme handler was simply:
      on updateme para
          put para into fld "theprogress"
      end updateme

The problem was nothing SEEMED to be getting through.
The initial text in fld "theprogress" stayed until the splash screen went away.
There were no lockscreens found in my handlers.
Changing the wait time did not help.
Placing a "put" to bring up and update the message box, did not help (it didn't update either).
Placing a BEEP or two and some breakpoints demonstrated that the messages WERE being sent during the startup.
Breakpoints DID allow the splash screen to update.

I am using the GLX framework and did not really want to see if there was any blocks within it.

Then I remembered the messages do get through to the "updateme" handler in the Splash stack!

Rather than try to find where things were locking up, why not just ensure it is unlocked when I need it.


Reply | Threaded
Open this post in threaded view
|

Re: updating progress to user during long handler

mwieder
On 02/26/2016 07:02 PM, jameshale wrote:

> Rather than try to find where things were locking up, why not just ensure it
> is unlocked when I need it.

Because locks and unlocks are paired. Screen locking increments a
counter, and unlocking decrements the counter. Once the counter reaches
zero the screen is unlocked again. If you just have a random unlock in
your code you may be messing with things elsewhere.

--
  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
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: updating progress to user during long handler

Kay C Lan
James,

Hmm, I thought I'd read you'd been advised to test if the screen was
locked, and you reported that it wasn't. Must have misread that.

Mark brings up a very good point. In your case, if it just so happened that
the were a couple of incremented lock screen, let's say 3, then a single
unlock screen would not have resolved your problem. A test of 'if the
lockscreen is true then beep' would have immediately led you in the right
direction.

For my own stacks, which typically don't need incremented lock screens, but
I lock the screen regularly, I use the simple:

if (lockscreen = false) then
  lock screen
end if
_______________________________________________
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: updating progress to user during long handler

Kay C Lan
oops, hit Send accidentally.

the above prevents me accidentally stacking lock screen and means I'm
only ever 1 unlock screen away from screen updates.

I think the preOpenStack/Card messaged automatically locks the screen
for you so their purpose can be achieved - positioning and preparing
your stack/card's appearance with default values etc prior to actual
display. It's neater and faster that way. If you removed the lock
screen you may be slowing things down.

_______________________________________________
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: updating progress to user during long handler

jameshale
Well I thought I should have a look given these comments.
I went through every GLX script I could find looking for lockscreens - none.
I then went through all my scripts in my main stack, the card scripts of the opening card as well as all library stacks I am calling.
Every lockscreen was paired (lock/unlock) within the handler it was located.
None of these handlers, BTW, were being called during the opening sequence.

Just to be sure I also added an if lockscreen = true then breakpoint at a couple of my progress points.

Launching the app it proceeded as wanted, updating the splash screen with progress reports until the screen displayed.
None of the lockscreen checks fired, indicating to me that there were actually no lockscreens were in effect during the startup.

So, I do not think there will be a problem as has been suggested.
I also can't explain why setting the lockscreen to false in the Splash stack makes things work.

As an aside when reading the dictionary on lockscreen it states that its setting has no effect in the IDE with script debug enabled.
I have script debug mode enabled.
I am also doing all this testing in the IDE.
If lockscreen has no effect in the IDE under these circumstances then why does setting the lockscreen to false allow things to work?

Curious, no?
12