Just in general, I’d say there are two common methods to alter widgets in specific rows of a repeater. In other words (if I understand your desire here) when the ‘x’ button is clicked on a chip, it needs to delete/filter/hide that row (seems to work now), and uncheck the corresponding row in the dropdown repeater, right?
Method 1: Make a “listener event” on a widget in the target repeater (your dropdown)
- Set a “signal” for the widget to “listen” for. This can be a global variable or text on any widget outside the repeater. It is a way to identify which row(s) should respond.
- For example, if you want only the 5th row to respond, set this “signal value” to 5
- Or, if you want only the row with text value of “Lorem ipsum” then set the signal value to “Lorem ipsum” --so in your case, you could set OnLoadVariable to [[Item.Chips]]
- Trigger the event for this widget. Because it is in a repeater, every row’s widget will fire the event (in rapid succession from first row to last row.)
- You can choose any otherwise unused event. Moved or Rotated are most common as most widgets within a repeater don’t get moved or rotated. Either would work well for your checkbox (which is actually an image–and that’s fine)
- To trigger this event, you would either call it directly (i.e., “Move **AlertsCheckbox by (0, 0)” --thus a “fake move”) or indirectly (i.e., “Fire Event Moved of **AlertsCheckbox”) --I prefer the latter as it is more obvious (to me) that the widget is not actually being moved–you are simply triggering its Moved event to use it as a special function–a listener event function.)
- Create a conditional case for this event so the widget can “listen for its signal” --ignoring if it doesn’t match and responding if it does match.
- For example,
MOVED
“If [[Item.Chips]] equals value of OnLoadVariable”
Set Selected/Checked of This to “false”
Set Variable Value OnLoadVariable to “”
// good housekeeping if only one row should respond
Method 2: Use a column in the target repeater to control the widget via Item Loaded
- Add a column to the repeater datasheet for the sole purpose of controlling your widget–just like your existing column to set a text value. For a checkbox it could be named “Checked”
- Set some boolean or binary logic, like possible values of ‘1’ or ‘0’ , or “true” and “not true” (i.e., “false”, blank, or literally anything else.)
- Add a conditional case to Item Loaded to control your widget
- in your case, it would look something like
"If [[Item.Checked]] equals “true” "
Set Selected/Checked of **AlertsCheckbox to “true”
- Note you do not have to handle “false” because the default selection state is false, so by default the checkbox will already be false/off.
- (except in your current repeater you have an action to "Set Selected/Checked **AlertsCheckbox to “true” --but I don’t know why)
- Be sure this conditional case is an “If” and not an “Else If” --you want it to be tested every time.
- So, to have a row checked by default, just set its Checked column value to “true” (or “1” if you use that logic) --any other value will keep it unchecked.
- To dynamically turn on a checkbox in a specific row, you would call Update Rows with a rule to define that row (or multiple rows if needed) and set the Checked column value to “true”
- Likewise, to uncheck a checkbox, do the same, setting the value to “false”
- For example, from your “CloseTag” widget:
Update Rows
AlertsLIst set Checked to “false” where “[[TargetItem.Alerts == Item.Chips]]”
- The “TargetItem” means "an item in the target repeater, and of course “Item” means "an item in this (or the “calling”) repeater.
- You can use the “Insert Variable or Function” link in the “Edit Value” dialog when creating your rules–or any expression–which greatly helps find and fill properties, like specific columns in a repeater. Just spin open “Repeater” and then click on the column name you need.
In my experience learning all this repeater stuff in this forum and reading threads over the years, the Listener Method seems like it is more commonly used. I’ve tended to prefer the “Column Control” method as it is easier for me and others to see and understand (and I work on Team Projects with many authors of varying Axure experience, as well as needing to revisit and leverage prototypes long after I created them.) I find it much harder to inspect and understand repeaters with deeply buried listener events. Also, the Column Control method is more extensible–you can always add more columns, but you’ll run out of unused events pretty soon. All that said, it is usually easier to “retro-fix” a repeater with a listener event versus rebuilding the datasheet and Item Loaded logic–particularly if you are sure you only need one simple thing, like checking/unchecking a checkbox. Hope all this helps you.
