Having to Wait(0)


#1

I’m in the habit of creating “functions” and “variables” for components or complex widgets in order to encapsulate their functionality. These are usually just hidden labels that have fake events attached to them, which are triggered by Fire Event.

As near as I can tell, Fire Event initiates a thread, and there’s no way to know for sure whether a previously fired event has completed before making decisions on that event’s outcome. (For another example of threaded behavior, look at Move animations. You have to put a Wait event afterwards that’s long enough for the Move to complete if you’re depending on the outcome of the Move.)

This gets more complicated with a series of IF statements. It seems to me that IFs are also threaded, and there’s no way to know that a previous IF completed before executing the logic of the next IF. So when a series of IFs launch a series of Fire Events it gets hairy quickly.

The “solution” tends to be liberally sprinkling Wait events all over the place to slow the code down. I feel like I’m fighting the Axure developers here, slowing things down while they try to speed things up (with aggressive threading). So:

  1. Is there any other solution that folks have found to blocking?
  2. Maybe a future feature request would be some way of declaring an IF or a Fire Event to be blocking?

#2

@axure

This is having follow-up effects in testing and deployment. Things that get fully tested as components don’t work in production because the wait time for threads to complete is more than what the designer accommodated.

For example, a component that works just fine in testing environments gets put into a bigger page that has much more going on. Those threads just don’t complete in time and the component gives the wrong results.