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.