In the previous blog post, we introduced TTMSFNCFilterView and looked at how users can filter data by interacting with familiar controls instead of building filter expressions manually.

Checkboxes, combo boxes, sliders, date pickers and other controls all contribute to the same structured filter in the background.

Now it is time to see how this works in practice.

In this blog post, we will look at two examples:

• Using TTMSFNCFilterView together with TTMSFNCDataGrid.
• Extending the Filter View with your own controls.

TTMSFNCFilterView and TTMSFNCDataGrid

The first video demonstrates how TTMSFNCFilterView can be combined with TTMSFNCDataGrid to create a modern filtering interface.

The Filter View contains the controls the user interacts with, while the DataGrid displays the resulting data.

Whenever the user changes a filter control, the underlying filter expression is updated automatically.

This means you do not have to manually combine all values into one filter string or write separate filtering logic for every control.

In the video, you will see how:

• Built-in filter controls are added to the Filter View.
• Each control is linked to a field and an operator.
• Multiple controls contribute to one filter.
• The generated filter is applied to TTMSFNCDataGrid.
• Different filter actions can be used to determine how matching data is displayed.

Configuring the Filter Controls

Every control inside the Filter View has an associated filter expression.

This expression determines what should be added to the filter when the user interacts with the control.

For example, a ComboBox can be linked to a country field:

FilterComboBox.FilterExpression.FilterFieldName := 'Country';
FilterComboBox.FilterExpression.FilterFieldType := fdtText;
FilterComboBox.FilterExpression.ExpressionOperator := feoEqual;

A CheckBox can represent a Boolean value:

Active = True

And a RangeSlider can contribute both a minimum and a maximum value.

Once these expressions are configured, the controls update their part of the filter automatically.

The application only needs to determine what should happen with the resulting filter.

Applying the Filter

Because TTMSFNCFilterView uses the same FilterBuilder structure introduced earlier in this series, the resulting filter can be used in different ways.

You can:

• Apply it to TTMSFNCDataGrid.
• Assign the generated filter text to a TDataSet.
• Validate individual rows.
• Validate a complete array of data.
• Use the filter with your own controls or object collections.

The Filter View is responsible for building and maintaining the filter, while your application remains in control of how the result is applied.

Using Your Own Controls

The built-in controls cover many common filtering scenarios.

However, an application may already contain controls that should become part of the filtering interface.

You may also want to use a control that is specific to your application instead of one of the standard Filter View controls.

The second video demonstrates how your own controls can be integrated into TTMSFNCFilterView.

This allows you to create a filtering interface that matches the rest of your application without giving up the structured filtering logic.

Filter View Control Container

One way to integrate an existing control is by using TTMSFNCFilterViewControlContainer.

The Control Container acts as a bridge between the control and a filter expression.

You configure the expression that the control represents:

ControlContainer.FilterExpression.FilterFieldName := 'Status';
ControlContainer.FilterExpression.FilterFieldType := fdtText;
ControlContainer.FilterExpression.ExpressionOperator := feoEqual;

When the control value changes, you update the value stored in the expression.

ControlContainer.FilterExpression.FilterValue := 'Office';
ControlContainer.FilterExpression.AddToFilter := True;

If the control represents an option such as All, the expression can simply be excluded from the filter.

ControlContainer.FilterExpression.AddToFilter := False;

This gives you control over the user interface while the Filter View continues to manage the complete filter.

Registering Controls Programmatically

Controls can also be registered directly with the Filter View.

This is useful when controls are created dynamically or when you want to connect an existing control without placing it inside a Control Container.

For example, a calendar can be linked to a date field:

TMSFNCFilterView1.AddCustomItemControl(
  FNCCalendar,
  FNCCalendar.SelectedDate,
  'Joined',
  fdtDate,
  feoSmallerThanOrEqual
);

When the selected date changes, the linked filter value can be updated:

procedure TFilterViewForm.FNCCalendarSelectDate(
  Sender: TObject;
  ADate: TDate);
begin
  TMSFNCFilterView1.UpdateCustomItemControlValue(FNCCalendar, ADate);
end;

The custom control now participates in the same filter as all built-in controls.

One Filtering Model, Different Interfaces

The important part is that the FilterBuilder does not need to know whether an expression came from:

• A built-in Filter View control.
• A control inside a Control Container.
• A custom control registered programmatically.
• A filter dialog.
• Code written by the developer.

All of these approaches create the same structured filtering model.

This keeps the filtering logic centralized while allowing the user interface to be designed around the requirements of the application.

Why Build a Custom Filter Interface?

A predefined filter dialog is useful when users need to create detailed or occasional filters.

A Filter View is more suitable when filtering is a regular part of the application workflow.

Users can immediately see the available filter options and adjust them without leaving the current screen.

By supporting both built-in and custom controls, TTMSFNCFilterView does not force your application into one fixed layout.

• You can create a webshop-style filter panel.
• You can use toolbar buttons for status values.
• You can use a calendar for date selection.
• You can combine different controls inside filter groups.
• You can reuse controls that are already part of your interface.

The user interface can be adapted to the application, while all controls continue to contribute to one consistent filter.

Less Repetitive Filtering Code

Without a shared filtering component, every control would usually require its own event handling and filtering implementation.

The selected values would then need to be combined manually before applying the filter.

With the Filter View, each control only defines the expression it represents.

The Filter View and FilterBuilder take care of combining these expressions, adding the required groups and generating the final filter.

This reduces the amount of repetitive filtering code and makes it easier to add or change filter controls later.

What's Next?

So far, we have used filter expressions to determine which data matches and which data should be displayed.

In the next blog post, we will look at how the same filtering logic can be used to trigger other behavior.

With TTMSFNCFilterRulesManager, matching a filter can change properties, control visibility, adjust appearance or trigger application logic.