Re: updating progress to user during long handler

[jameshale]

Thanks for the inelegant solution Phil.
Although given I didn't find any to unlock (despite the unlock screen
getting things to work) I trust I do not need it.
Thanks Kay for the interpretation of the dictionary entry.
Makes perfect sense.
Opportunity for an edit to the entry I guess.

We can probably put this thread to bed now.
Thank you all for your help



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701584.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: updating progress to user during long handler

[Kay C Lan]

On Sat, Feb 27, 2016 at 2:48 PM, jameshale  wrote:
>
> 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?
>
I think what that means to say is that you are not in Debug Mode until
you actually hit a breakpoint and you step through your code, stepping
onto lock screen will have no effect. It's pretty easy to test:

Run once then comment out the breakpoint and run again.

New stack, 1 button, 1 field. In the btn:

on mouseUp
   put empty into x
   repeat with x = 1 to 500
  put x into fld 1
   end repeat

   put empty into fld 1
   wait 1 sec
   --breakpoint
   lock screen
   repeat with x = 1 to 5000 --yes 5000*
  put x into fld 1
   end repeat
end mouseUp

* Just to demonstrate how unlocking the screen slows things down... A LOT.

___
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

Re: updating progress to user during long handler

[Phil Davis]

Here is an inelegant but effective way to handle an unknown number of 
nested lockScreens:


put 0 into x
repeat until the lockScreen is false
unlock screen
add 1 to x
end repeat

-- put your update indicator code here

repeat x times
lock screen
end repeat


Then you don't have to search far and wide for the culprits. And you 
leave the lockScreen environment as you found it.


Best -
Phil Davis



On 2/26/16 10:48 PM, jameshale wrote:

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?



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701572.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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



--
Phil Davis


___
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

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?



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701572.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

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

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

Re: updating progress to user during long handler

[Mark Wieder]

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
 ahsoftw...@gmail.com

___
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

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.






--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701566.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: updating progress to user during long handler

[Dr. Hawkins]

On Thu, Feb 25, 2016 at 7:28 PM, 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
>

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

Re: updating progress to user during long handler

[Richard Gaskin]

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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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

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

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 

> james@.id

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





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701498.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: updating progress to user during long handler

[Kay C Lan]

On Fri, Feb 26, 2016 at 9:56 AM, jameshale  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
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

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.



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701491.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: updating progress to user during long handler

[Kay C Lan]

On Wed, Feb 24, 2016 at 9:24 PM, jameshale  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
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

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.




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701358.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: updating progress to user during long handler

[Phil Davis]

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



--
Phil Davis


___
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

Re: updating progress to user during long handler

[James Hale]

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

Re: updating progress to user during long handler

[jameshale]

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.



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701339.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: updating progress to user during long handler

[jameshale]

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.



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/updating-progress-to-user-during-long-handler-tp4701326p4701338.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: updating progress to user during long handler

[Mark Waddingham]

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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: updating progress to user during long handler

[dunbarx]

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 <ja...@thehales.id.au>
To: use-livecode <use-livecode@lists.runrev.com>
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
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

___
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

updating progress to user during long handler

[James Hale]

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