Bidirectional SQL binding firing too soon

The technique I use in Ignition to distinguish regular binding traffic from user input is to never bind a user input field directly to a source of data. I always place a custom property of the appropriate type on that field, usually named “raw”, and bind that to the source. Bidirectionally if a tag. Then I bind the input field’s editable property uni-directionally to the raw property.

With the above, a property change script that captures a change to the input field property first checks if the new value matches raw. If so, the value came from the binding and nothing need be done. Otherwise, it is a user input and action is appropriate. Calling an update SQL and then refreshing the source binding would be the action in your case.

Personally, I hate automatic writeback. To facility a great user experience, I add another custom property to each input field, boolean, called “dirty”, and bind it to an expression that is just {Root Container.SomeField.raw} != {Root Container.SomeField.text}. I then style the input field to have a colored background when dirty.

I then have a save button and a cancel button. Each is enabled when any input field is dirty. The cancel button just loops through the container recopying raw to the input property. The save button assembles the appropriate SQL, fires it, and then refreshes the source binding. When that binding finishes, the colored background disappears everywhere. If the source for the fields are tags, bidirectionally bound, the save script simply loops through the container copying from input property to raw (opposite of cancel).

3 Likes