It is important to realize that commands in Axure–as with most programming languages–are ballistic. Just like throwing a ball or shooting a bullet, once you do it, it goes and you can’t undo it. When you are using motion or animation effects that take time, you need to account for that time or things will get out of sync. The built-in animation effects (you are using the “fade” animation effect) can’t be interrupted or stopped once initiated. (Also realize that “commands” are really just requests --if the system has the resources to perform the action it will, otherwise it may get lost or “ignored.”)
So, if you make a widget hide with a 500 ms fade animation, it will perform that fade over a duration of 500ms, and any actions issued to alter the visibility property during that 500ms won’t take effect until that 500ms elapses. Also, if you issue a chain of actions with animation (of the same property, like visibility) one after the other, they will stack and be performed one after another (or in some cases have no effect.) If you have this sequence of actions:
Hide MyWidget fade 500ms
Wait 100ms
Show MyWidget
…All three actions get fired immediately one after the other–and the “browser graphics engine” handles them in sequence, first by requesting MyWidget be hidden with a fade effect over the course of 500 ms; if MyWidget is ready, it accepts this request and hides. Then a 100 ms timer is started. When that timer elapses, another request is made to show MyWidget–but since MyWidget is busy already, that “show” action doesn’t happen until the ongoing hide animation is completed. So, these three actions would result in MyWidget fading out to fully hidden over the course of 500 ms, then be shown. It would NOT start to hide MyWidget for the first 100 ms then show it at that 100 ms time mark. It would NOT hide MyWidget for 500 ms, then after fully hidden wait 100 ms, then show it --so the whole sequence of events would take about 500 ms, not 600 ms.
Let’s look at the “Level Control” dynamic panel I created and set to repeatedly change states every 500 ms. When st_BlinkAct is set to “true” then the first time it changes states it causes an indicator widget to hide with a 500ms fade animation. The second time it changes states, it shows that indicator, which should be fully hidden because 500ms has elapsed, and so forth. The command to show/hide is synchronized with the change of states (the loop.)
When you made the dp change states every 100 ms, that would result in essentially 5 requests to toggle visibility of a widget over the course of time it takes to perform just one visibility change (hide or show with 500ms fade effect.) So, let’s say you click the “Start Blinking” button and one second later click the “Stop Blinking” button. There would be roughly 10 requests made to show/hide an indicator widget, all of which get stacked up behind each other and performed “when ready” --at 500 ms intervals. Keep in mind, once you invoke these actions they cannot be recalled. So rather than blinking twice, it would blink about 10 times. Likewise, if blinking is on and “ind_1” is set to hide/show, then you move the slider to cause “ind_2” to hide/show that will happen, but “ind_1” would still have lots of requests to hide/show still stacked up, so for awhile both “ind_1” and “ind_2” would blink–depending on how long the slider sat at position 1 before being moved to position 2.
Rather than “skipping cases” the cases are processed properly, but too fast, so their intended actions get caught up in a traffic jam. Going back to my “ballistic ball” metaphor, it is like you’ve dropped a whole bunch of balls down a tube just wide enough to fit one ball. The balls can only get through the end of the tube one at a time, and there’s no way to reach into the tube to pull balls back up.
For your scenario, there are several ways you can try to avoid this traffic jam.
-
Suck it up and live with 500 ms responsiveness 
-
Keep “Level Control” changing states every 100 ms but process “blinks” only every 5th loop iteration–which should be 500 ms, the same as your show/hide animation fade effect duration.
- You can do this by incrementing a counter at every loop, then using a modulus function in your case logic.
- The case logic expression would look like,
If [[MyCounter % 5]] equals 0
-
Directly control the “Level Control” dynamic panel with your button clicks and slider moves. Rather than set a global variable and wait for up to 500 ms for “Level Control” to process that change, issue an action to Set Panel State of “Level Control” to next, wrap repeat immediately.
-
Instead of trying to manually control your animations in Axure, create animations in a graphics app, save them as looping animated GIFs and hide/show these with one action instead of a looping series of actions. I think this would be the most reliable way to ensure you are not showing two blinking indicators at once or getting animations out of sync.
- For example, create an animated GIF for a single blinking indicator. Move it to the same position and in front of the indicator you want to blink and show it.
- Or, create a dynamic panel with one state per blink/static. With 5 “battery levels” each of which could be static or blinking, this would be 10 states in a dynamic panel.