Hello,
If you have a tag binding on a numeric text field that was not set to bidirectional and you have a button change the value of that field, the field changes to what the button tells it to but the tag itself does not.
In my opinion, the button script should attempt to change the field but the binding on the field should block it instead of changing the field value but not the tag.
That’s not how bindings have ever worked, in Vision or Perspective. As soon as the tag value changes again, the change sent from the button will be overwritten. What you’re describing would be a breaking change from how bindings have always worked - at minimum, one more thing to configure for every single binding.
The button should write to the tag, not the field.
I see what your saying but I will say it can be kind of misleading that when you bind a field to a tag, that the field can actually display something that is different to the bound tag.
Is that like a best practices thing? Doing things this way as standard practice would certainly ensure that the field’s displayed value is the same as the tags value.
Actually, it is very useful when implementing a user interface that writes many fields back to corresponding tags when a user clicks a "save" button or otherwise confirms.
Consider adding a couple custom properties to each of your fields:
Dirty, andRaw that matches the type of the field.Move your field's tag binding to the Raw property and make it bidirectional. Add a unidirectional property binding to pull the raw value to the field's editable property. Add an expression binding for Dirty that compares Raw != field value.
Style your field with Dirty. (I like yellow backgrounds for fields with unsaved changes.)
The save button actionPerformed script would copy all of the dirty fields editable property to the Raw property, letting the bidirectional binding handle the tag write.
Without unidirectional bindings, bulk "save" or "confirm" logic would be much more trouble.
Thanks for your time in explaining!