In the general model of data binding, a data source has no semantic understanding of any controls that are bound to it. In the ABL model, this means that the ProBindingSource does not know what .NET controls are bound to it. The ProBindingSource presents the data for any control to use, and the .NET control accesses the data that it can use.
However, without a semantic understanding of the controls, ABL data-handling statements cannot provide the automatic behaviors that you see with ABL UI widgets. For example, the ABL statement, "DISPLAY customer.name.", cannot create an Infragistics.Win.UltraWinEditors.UltraTextEditor, set its format properties, and provide an Infragistics.Win.Misc.UltraLabel as a default label.
Instead, your application must explicitly create the .NET controls and set their properties. If you have worked with dynamic ABL widgets, you are familiar with this style of programming by setting widget attributes. You cannot use the ABL data-handling statements to manipulate screen values in .NET controls. Your application must perform such tasks through object manipulation.
The reverse case is also true: bound .NET controls have no direct understanding of the bound ABL data source objects. The .NET controls cannot access the schema of a bound ABL data source object to find the default format, validation phrase, or help text for a field. The .NET controls can only access what the binding interfaces in the Progress.Data.BindingSource class make available.
