Resolution: TIBCO Business Studio Forms uses bindings to update properties in the runtime forms data model by connecting attribute values of parameters, controls and panes. A binding always has two endpoints. The type of endpoint determines the direction of the binding.
1). Primitive values and secondary properties.
Values can be a source and a sink. If the binding is specified as synchronizes (assuming the other endpoint supports it) then a change at either end of the binding will affect the other end. This is the default type of binding set up between controls and parameter values.
Other properties on a control are considered “secondary” properties and can only act as a sink in a binding relationship. That is, these values can only be “updated by” the other end of the binding endpoint. This means, for example, you cannot change the visibility on a control and expect to drive the other end of the binding endpoint. This is the case for both the built-in secondary properties such as enabled, visible, required, etc,, along with any additional configuration properties particular to a custom control definition.
2). Complex Objects.
Complex objects will always act in a “synchronizes” fashion. For example, if you bind a pane value to a complex parameter, those two endpoints share the same object and either endpoint will share updates to the other. This should be the case whether the complex object is the value or property of the control. If you are able to see a situation where a binding from one complex object, the complex property of a control can be configured as “updates” instead of “synchronizes”, Note, this is a reference to direct bindings between the complex objects themselves and not primitive attributes that are members of those objects. It is still possible to create a one-way binding to an attribute of a complex object.
Direct bindings between complex objects is always in "synchronizes". This decision was made for performance reasons. Since complex objects can be arbitrarily large, we wanted to avoid situations where a simple action, such as setting up a one-way binding, would result in the copying of a large object, with the ongoing hit that we take to keep the copy in sync with the source. By only allowing a two-way binding for complex objects, we are able to use the same object for both end points.