e 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 Nabbl
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 eff
ext:
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
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
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 st
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
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
ng 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.
_
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. R
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
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 open
is 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
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
age 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 t
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 imme
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-lo
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
scr
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 i
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
'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 l
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
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
To: use-livecode
Sent: Tue, Feb 23, 2016 9:25 am
Subject: updating progress
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 tryi
23 matches
Mail list logo
