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
