# Message from Flex Repeater view is reaching message handler before the parameter binding

**URL:** <https://forum.inductiveautomation.com/t/message-from-flex-repeater-view-is-reaching-message-handler-before-the-parameter-binding/44448>\
**Category:** Ignition\
**Tags:** perspective, scripting\
**Created:** [March 14, 2021, 9:03pm UTC](https://forum.inductiveautomation.com/t/message-from-flex-repeater-view-is-reaching-message-handler-before-the-parameter-binding/44448 "2021-03-14T21:03:58Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\
**Post date:** [March 14, 2021, 9:03pm UTC](https://forum.inductiveautomation.com/t/message-from-flex-repeater-view-is-reaching-message-handler-before-the-parameter-binding/44448/1 "2021-03-14T21:03:58Z")

</div>

I have a Flex Repeater component with each view consisting of a Checkbox component.

```auto
Flex repeater
    [] Option 1
    [x] Option 2
    [x] Option 3
    [] Option 4

```

The Checkbox view has a bi-directional binding to the checkbox view params. This is also working.

```auto
PARAMS
    checked <-->

```

Clicking an option sends a message which is picked up by message handler in the Flex Repeater root and this will store the checked options in a database table.

This is message handler is working but it’s always one step behind the last option selected. If I now select Option 4 the message handler will show me that Options 2 and 3 are selected. If I deselect Option 4 then the message handler will show that options 2, 3 and 4 are selected.

I’ve tried to force the subview’s “checked” binding to update first (see below) but to no avail.

```auto
	system.perspective.print("Checkbox click in viewRoleCheckbox.")
	# There's a strange problem here. The message gets back to the popupSelectRoles before the "selected" binding 
	# updates the bi-directional "checked" property. 
	self.view.params.checked = self.props.selected # Let's force the bi-directional binding first.					
	payload = {'sessionID': self.session.props.id}
	messaging.broadcastPerspectiveMessage("updateAuthorisations", payload)

```

(To understand the _broadcastPerspectiveMessage_ function see [http://forum.inductiveautomation.com/t/when-to-refresh-the-binding-on-a-table-edited-by-multiple-clients.)](http://forum.inductiveautomation.com/t/when-to-refresh-the-binding-on-a-table-edited-by-multiple-clients.))

Any ideas?

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [March 14, 2021, 11:37pm UTC](https://forum.inductiveautomation.com/t/message-from-flex-repeater-view-is-reaching-message-handler-before-the-parameter-binding/44448/2 "2021-03-14T23:37:40Z")

</div>

If I’m understanding your set-up correctly, you’re waiting on a message to determine when you should write values, but this leaves your session open to a sort of con: The Wire con. In a wire con, the “mark” is looking at out-of-date information (like a delayed race) and making wagers based off of faulty information. Your message handler is directing your session to look at information which hasn’t been synchronized with the View it’s representing. You should not use messaging for this, or your messaging should _include_ the information you want.

These three options might be “better”:

A. Move the database write to the View, and use the params supplied to the View to build whatever query you’re using. This would prevent the need to wait on the view to update and write back to the Flex Repeater or listen for an incoming message as the View is handling the update without needing to send the message.  
B. Write the checkbox value as part of the payload the View is sending to the Flex Repeater so that you’re always writing the correct value instead of waiting on a telephone call to provide guidance on when to check a possibly unsynchronized value.  
C. Instead of using messaging, just put a change script on the params of the flex repeater; this would allow you to write whenever the Flex Repeater becomes synchronized.

---

<div class="post-metadata">

**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\
**Post date:** [March 14, 2021, 11:47pm UTC](https://forum.inductiveautomation.com/t/message-from-flex-repeater-view-is-reaching-message-handler-before-the-parameter-binding/44448/3 "2021-03-14T23:47:24Z")

</div>

Cool.  
I like the sound of option C but how do I do it? The number of instances in the Flex Repeater is dynamic so what do I attach the change script to?

* * *

Oops, I’ve discovered a right-click, Add Change Script option on the instances. Does that monitor all the parameters? I’ll give it a go.

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [March 15, 2021, 3:44am UTC](https://forum.inductiveautomation.com/t/message-from-flex-repeater-view-is-reaching-message-handler-before-the-parameter-binding/44448/4 "2021-03-15T03:44:58Z")

</div>

> [@Transistor](#):
>
> Oops, I’ve discovered a right-click, Add Change Script option on the instances. Does that monitor all the parameters? I’ll give it a go.

Yes, placing the change script there will monitor all of the parameters across all of the instances.