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 proba
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
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 sear
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 (l
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
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.
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
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
>>
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
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
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-long-handler-tp4701326p47
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 th
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
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
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 use
22 matches
Mail list logo
