LiveBindings in RAD Studio: Declarative UI‑to‑Data Sync Made Simple

Why LiveBindings Matters

When you build a VCL or FireMonkey form that shows data, the usual pattern is to write code that copies values from a model object to UI controls and back. That boilerplate is error‑prone and hard to maintain. LiveBindings lets you declare the relationship once and let the framework keep the UI and data in sync automatically.

How LiveBindings Works

At its core LiveBindings uses a small set of components:

• TBindSourceAdapter – exposes a plain Delphi class (or record) as a bindable source.
• TLinkFillControlToField – connects a control property (e.g., TEdit.Text) to a field or property of the adapter.
• TBindingsList – owns the links and manages the binding engine.

When the source raises NotifyChanged or a control fires an event (e.g., OnChange), the engine evaluates the expression string and propagates the value to the bound side. The direction can be set to one‑way, two‑way, or include a custom converter for formatting or validation.

Example: A One‑Way Text Binding

Suppose you have a simple data class:

type
  TPerson = class
  private
    FName: string;
    procedure SetName(const Value: string);
  public
    property Name: string read FName write SetName;
  end;

procedure TPerson.SetName(const Value: string);
begin
  if FName <> Value then
  begin
    FName := Value;
    // Notify the binding engine
    if Assigned(FOnChange) then FOnChange;
  end;
end;

In the form’s OnCreate you can wire the binding in code:

procedure TForm1.FormCreate(Sender: TObject);
var
  Person: TPerson;
  Adapter: TBindSourceAdapter;
  Link: TLinkFillControlToField;
begin
  Person := TPerson.Create;
  Person.Name := 'Ada';

  Adapter := TBindSourceAdapter.Create(Self);
  Adapter.DataSet := nil; // not a TDataSet
  Adapter.AdapterObject := Person;
  Adapter.OnChange := Person.OnChange; // hook up notification

  Link := TLinkFillControlToField.Create(Self);
  Link.Control := Edit1;
  Link.ControlProperty := 'Text';
  Link.Source := Adapter;
  Link.SourceField := 'Name';
  Link.Mode := bmOneWay; // UI reads from source only

  BindingsList := TBindingsList.Create(Self);
  BindingsList.Active := True;
end;

Now, typing into Edit1 will not change the source, but any change in Person.Name (e.g., from code) will instantly update the edit box and any other links you create.

Example: Two‑Way Binding with a Converter

To format the name in uppercase on the UI while keeping the source unchanged, use a converter expression:

Link.ControlProperty := 'Text';
Link.SourceField := 'Name';
Link.Expression := 'UpperCase({Source.Field})';
Link.Mode := bmTwoWay;

When the user types "bob", the edit shows "BOB" but the underlying Person.Name remains "bob".

Common Pitfalls and How to Avoid Them

• Nil Source: If the adapter’s AdapterObject is nil, bindings silently fail. Always instantiate the source before activating the list.
• Exception in Converter: A malformed expression or runtime error in a converter will be swallowed. Wrap expensive logic in try..except and return a safe default.
• Mixed Manual Updates: Writing directly to a bound control inside an event that the binding also listens to can cause flicker or stale data. Either disable the binding (Link.Enabled := False) before the manual write or rely solely on the binding.
• Performance on Large Collections: Binding each item in a large TListView can degrade UI responsiveness. For thousands of items, consider a virtual list view or manual data population.

Testing the Binding at Runtime

1. Run the application and type into Edit1; the label updates instantly.
2. In the IDE, set a breakpoint in TPerson.SetName and change the value programmatically; observe the UI reflecting the change immediately.
3. To benchmark, create a loop that assigns a new name 10,000 times and measure the frame rate. Compare against a direct assignment loop; the binding adds a measurable overhead.

When to Use LiveBindings

• Simple forms with a handful of controls.
• Scenarios where the data model changes infrequently.
• When you want to separate UI logic from business logic without writing repetitive code.

For high‑performance, data‑heavy applications, consider manual updates or a virtualized UI component.