Revolution is single-threaded, and when you use "wait with messages" the next button will effectively block the first until it is done, and then the first button resumes.
You may be better off with the 'send in time' construct. This allows you to tell the engine to send a message to the same or another control in x seconds or milliseconds at the earliest. These will then be placed onto a queue, and executed one after another when no event handlers are running.
For istance, if you make a stack with a single button and set it script to
Code: Select all
on mouseUp
answer "Hasta la vista, baby..." with "I'll be back"
send "ComeBack" to me in 2 seconds
end mouseUp
on ComeBack
answer "I told you I'd be back!"
end ComeBack
then click the button, you get the first answer dialog box, and when you close that, two seconds later you'll get another message.
The message that you send can also have parameters. Let's finetune the previous example a bit
Code: Select all
on mouseUp
answer "Hasta la vista, baby..." with "I'll be back"
put the long system time into tStartTime
send "ComeBack tStartTime" to me in 2 seconds
end mouseUp
on ComeBack pStartTime
answer "Around" && pStartTime && "I told you I'd be back!"
end ComeBack
when you click the button this time around, it will tell you when you closed the first answer dialog box. Admittedly a rather whimsical example, but it shows how you can pass parameters to a send message.
You can use this both for one time operations, and to schedule messages at a regular interval, like a timer service. Let me give you an example of a timer. Suppose we have a stack with a field "CurrentTime" and a single button "StartStop" that will handle "Start" and "Stop". Here's the script for our "StartStop" button.
Code: Select all
local sMessageID
on mouseUp
if sMessageID is empty then
-- start the timer
send "ShowTime" to me in 500 milliseconds
put the result into sMessageID
set the label of me to "Stop"
else
-- stop the timer
cancel sMessageID
put empty into sMessageID
set the label of me to "Start"
end if
end mouseUp
on ShowTime
put the long system time into field "CurrentTime"
send "ShowTime" to me in 500 milliseconds
put the result into sMessageID
end ShowTime
Click the button, and the field "CurrentTime" will be regularly updated with the long system time until you click the button again. If you want more information regarding the messages system, I highly recommend the
Primer on Message Mechanics that Dar Scott put together back in 2003.
So my suggestion is to break down the repeat loops into events that you can 'send in time' to trigger their execution. Use parameters to keep track of the iteration(s) you're in, and take it from there.
HTH,
Jan Schenkel.
