Basically all you have to do is create a conditional case with “no logic” --meaning no conditions have been set. This is the default Case when you “Enable Logic” in an event, and results in a case that reads,
“If true …” --meaning it will always be run when that event is triggered, because true is always true (despite what some politicians, clerics and other con artists might say! 
)
Here is a basic demo in a repeater:
If True in a repeater.rp (59.9 KB)
The interaction code for the widget in the repeater is:
So, when row.BoxA is clicked, every “If” case will be evaluated by the code. The “Else If” cases will only be evaluated if the prior case is false.
-
Case 1 will always be true so it will always set This to selected (= “true”) and the dynamic panel dp.A to the state named, “Default”.
- (Furthermore, I designated a selection group so only one row/widget can be true.)
-
Case 2 will evaluate if [[Item.Column0]] (the text in the column named “Column0” in the repeater’s style sheet for the current row) equals “Apple”. If it is, it sets dp.A to the state named, “Red”.
-
Case 3 will only be evaluated if Case 2 is false. If Case 2 is true (text in Column0 is “Apple”) then there is no point in evaluating Case 3 or Case 4.
- Likewise, Case 4 will only be evaluated if Case 3 is false.
When row 1 is clicked, only Case 1 is triggered–because no other conditions would be true–so it will be selected (color changes to blue) and dp.A remains in its “Default” state. When row “Apple” is clicked, Case 1 sets it to selected and dp.A to “Default” but Case 2 is also true so dp.A is set to “Red”. If row 2 is then clicked, it gets selected and dp.A is set to “Default” --but nothing else happens because no other conditions are true.
This demo works (at least for me on Win10 and Chrome) but there is a caveat… It is not guaranteed to necessarily always work. This is because you can’t really control the order of the cases being evaluated. It should be (and I believe it is so for most browsers) that an “If true” case is always evaluated first–before any conditional cases, then the first “If” case, then any “Else If” cases. In fact, if you move Case 1 to the bottom of this list it still works the same. But, if you have some long or complicated actions to perform, their timing may become random and/or overlap with each other. In this simple example, there is not much happening, but it could potentially result in the panel state changing to “Red” first and then to “Default” instead of the other way around. One way to get around this would be to put a “Wait 10ms” action in the conditional cases–just before the Set Panel State action to ensure it happens after the “If true” case actions.
Another caveat… If you first create an “If true” case and then add another case Axure will by default assign that second case as an “Else If” case (Why? I have never understood!) which means it would never get triggered–because it equates to “Else if true is not true”. So, be sure to double-check your conditional cases and make sure they are properly set to “If” or “Else If” as needed. Otherwise, you can get some confusing bugs that can be difficult to debug. In your example screenshot above, your cases are all “If” conditions, which should work OK in your example, but it would be more efficient (especially for more complex interactions and/or large repeaters) if you used “Else If” conditions.
True… but you can use the Click or Tap event to trigger another event (or multiple events) by using Fire Event. You can make use of an existing event that you’ve coded or trigger an otherwise unused event. This can effectively result in “another kind of Click event”. Let’s say you always wanted to set ++CellA to “true”, then set the dynamic panel state conditionally, then after all that is done, do something else, like say, wait briefly so the user can see the change and then set the focus on another widget. You could include in the “If true” case:
…
Wait 1000ms
Fire Event Rotated of This
…then use the Rotated event to set focus on another widget or whatever.
