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

Ignition
,
1

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

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.

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.

	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.)

Any ideas?

2

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.

3

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.

4

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