Property Binding Overview

Property Binding is perhaps the most important concept to understand when designing a project using the Vision module. It is primarily through property binding that you bring windows to life, and have them do useful things.

When you initially place a component on a screen, it doesn't really do anything. Changing its properties in the designer will make it look or act different, but it has no connection to the real world. This is what property binding adds. Property binding, as its name suggests, lets you bind a property to something else. That something else might be:

For example, bind the value property of an LED Display to an OPC SQLTag, and voilà - the value property will always be the value of that tag - creating a dynamic display. Bindings can also work the other way, using a bidirectional binding. Bind the value of a numeric text box to a tag, and that tag will be written to when someone edits the value in the text box.

The power of property bindings comes from the variety of different binding types that exist, and the fact that you can bind nearly any property of a component to anything else. Want its foreground to turn red when an alarm is above a certain severity? Bind its LED Lit (glyphForeground) color to a tag's AlertCurrentSeverity property. Want it to only appear if a supervisor is on shift? Bind its visible property to the result of a SQL query that joins a personnel table with a shift table. The possibilities are, quite literally, endless.

How Bindings Work: Event-based vs Polling

While there are quite a few different binding types, they all boil down into two broad categories. Some complex bindings can span both categories.

Event-based bindings are evaluated when the object they are bound to changes. For example, when you bind a property to a SQLTag, that binding listens to the SQLTag, and every time the tag changes, it assigns the tag's new value into the property that it is on. If you bind the value of a Cylindrical Tank to the value of a Slider, then every time the slider changes, it fires a propertyChangeEvent. The binding is listening for this event, and when it is fired, updates the tank's value. The following bindings are event-based:

Polling bindings are evaluated when a window first opens, on a timer, or when they change. For example, if you bind the data property of a Table to the results of a SQL query, that query will run on a timer, updating the Table every time it executes. The following bindings are based on polling:

Many bindings can combine elements of a polling binding and event based binding. An expression binding may combine lots of other bindings to calculate a final result. A query binding will often itself be dynamic, altering the query based on other bindings.

For example, you might have a dropdown on a window that lets the operator choose a type of product that is produced. Then you can use a query binding like this to calculate the defect rate for the given product:

SELECT
   SUM(defective) / COUNT(*) AS DefectRate
FROM
   production_table
WHERE
   productCode = '{Root Container.ProductPicker.selectedValue}'

The red code is a binding inside of the query binding. Every time this (event-based) binding fires, the query will run again.

Using bindings like this, you can create highly dynamic and interactive screens with no scripting whatsoever.