Running Concurrent Animations

[Not a lot of thought]

I've tried searching this topic and haven't had much luck. Perhaps I am not using the right terminology. I would like to run multiple animations at once. Example: say I have two progress bars that once the card is open begin expanding to give the user the actual status of something. I want one to start a few ticks after the other, but I want them both to be expanding at different rates but simultaneously. So start one then the other but both be moving concurrently.
I've tried using a send message to send a handler to a different object but the code stops until that line is executed entirely in the test environment even if it is calling a different object's handler then it moves on to the next line. So what I end up with is start one status bar *repeat loop until it reaches the designated size* then it starts the next one.
Does anyone have any suggestions or tutorials they might recommend?

[dunbarx]

Hi.

There should be no issue with running two processes, something like(pseudo):

Code: Select all

repeat until you are satisfied
  set the thumbPos of scrollbar 1 to someNewValue
  wait a little with messages
  set the thumbPos of scrollbar 2 to someOtherNewValue
  wait a little more with messages
end repeat

There are other ways as well, like running two handlers that communicate between them until either they or you are satisfied.

Craig Newman

[Not a lot of thought]

Thanks Craig! That helps for the progress bars. I'll just have to write an if to pass over one if it is finished and the other not. However, I have several hundred items to update at one time and I think it would be difficult to write a repeat statement that satisfies all of the objects. Could explain what you mean by multiple handlers that communicate? Pseudo code is fine.

[dunbarx]

Hi.

Do you mean that you have, for example, several hundred progress bars that each need updating at their own rate? Or several hundred somethings?

If so, each will need its own little code section, unless some schema can be applied to groups of them. Are you worried about speed? I bet this is not an issue.

Craig

[jacque]

I wouldn't use a repeat loop here, you were on the right track with the "send" command. It only needs a time parameter to work.

The way I'd manage this, especially if you have many progress bars, is to create a behavior and assign it to each progress bar. Each bar would have a custom property specifying the number of seconds (or milliseconds) between updates, and a handler that specifies what actions should be taken during the update. A handler in the main script where you have the repeat loop now would trigger all the progress bars and after that they would take care of themselves.

General idea for the behavior script:

Code: Select all

on updateMe
  doProcessing -- a handler in each progress bar that does the actual work for this bar's task
  incrementProgress -- increment the progress bar's visual display
  put the cInterval of me into tInterval
  send "updateMe" to me in tInterval seconds
end updateMe

Each progress bar would contain a "doProcessing" handler that does the work for that particular job. I'd keep the number of repeats fairly low so that one progress bar's update doesn't stall out the rest of them, or at least add a "wait 1 millisecond with messages" to the repeat to give time to the other running handlers. Or if there aren't too many objects to update, do only one at a time and avoid repeats entirely.

This is more a concept than an example but maybe it will give you some ideas.

[bn]

Hi,

here is an example stack that lets you register 8 scrollbars to a "gameLoop". The gameLoop is a central loop that loops at fixed intervals and sends a message to registered "members" of the loop.

This sounds very complicated but in fact it is quite strait forward once you get your head around it. The loop governs the intervals of refresh and the members act individually on the trigger message they get from the GreatLoop.

I made two kinds of scrollbars, 1. "real" scrollbars" and 2. progress bars. They all have a custom property that determines the step size of the increment called "inc". All scrollbars (real and progress) have the same behavior script assigned to them. It is button "behavior", which is "disabled" to not accidently trigger it.
Look at the card script how the gameLoop or what I call the GreatLoop works. How one registers a member (see start loop xxx buttons for how to) and the script of the behavior how a member unregisters once a threshold is reached.

you can hit the start buttons while the loop is running etc.

Finally there is one button to prematurely stop the "GreatLoop"

Kind regards
Bernd