In our previous blog post, Creating a Database Report Generator with TMS FNC DataGrid , we created a flexible report generator capable of loading database data and exporting the current view to several different formats.

This time, we're taking that same project a step further.

Instead of focusing on generating the report, we want to give the user more control over what they see and how they see it.

For this, we've added:

• Filtering
• Advanced filtering
• Conditional formatting
• A built-in conditional formatting editor
• Saving and loading formatting and filter settings

What makes these additions particularly interesting is not only what they add to the application, but how little code is actually required to enable them.

A lot of this functionality is already built directly into TTMSFNCDataGrid.

Starting from our Report Generator

We'll continue with the database report generator from the previous blog post.

That project already takes care of connecting to the database, displaying the data in TTMSFNCDataGrid, and exporting the resulting report. We won't repeat that implementation here.

Instead, we'll focus entirely on making that data more interactive.

Adding Filtering: One Line

Giving users the ability to filter the data displayed in the grid requires:

Grid.Options.Filtering.Enabled := True;

That's it.

With one property, the DataGrid gets its filtering interface.

In the sample, we've exposed this through a checkbox:

Grid.Options.Filtering.Enabled := CheckFiltering.IsChecked;

The user can now enable or disable filtering without us having to create a separate filtering interface, parse values or manually build a filtering system around the grid.

This is a good example of the low-code approach behind the DataGrid: enable the capability and let the component provide the UI and behaviour.

Need More? Enable Advanced Filtering

For more complex datasets, a simple filter value isn't always enough.

A user might want to specify whether a value should be equal to, greater than, smaller than or otherwise compared against another value.

For that, we can switch the existing filtering functionality into its advanced mode:

Grid.Options.Filtering.Advanced := True;

Again, we're talking about one line of Delphi code.

Instead of building an advanced filter interface ourselves, the DataGrid provides the richer operator-based filtering UI.

In our application, the user can switch between both modes:

Grid.Options.Filtering.Advanced := CheckAdvancedFilter.IsChecked;

This means we can progressively expose more functionality without making the basic interface more complicated than necessary.

Enable filtering when you need it. Enable advanced filtering when you need more control.

No separate filtering system needs to be developed.

Conditional Formatting: A Brand-New DataGrid Feature

Filtering helps users find the information they're interested in. Conditional formatting helps them see important information immediately.

Conditional formatting is a brand-new feature in TTMSFNCDataGrid. We introduced the feature in more detail in:

our dedicated conditional formatting blog post .

If you want to learn more about the available rules and how conditional formatting works internally, that blog post is the best place to start. Here, we'll focus on how easily we can add it to our existing report generator.

Enabling conditional formatting requires:

Grid.ConditionalFormatting.Enabled := True;

Once again, one line is enough to enable an entirely new layer of functionality in our application.

Conditional formatting can then be used to visually distinguish values using rules such as:

• Data bars
• Colour scales
• Top-N values
• Value-based highlights

This can turn a regular table of database records into something much easier to scan and interpret.

Let the User Create the Rules

Enabling conditional formatting is useful, but we don't necessarily want to decide all the rules beforehand.

The person using the report may know much better which values deserve attention.

So why not give them access to the built-in conditional formatting editor?

Grid.Root.ShowConditionalFormattingEditor;

With this single call, we can open the DataGrid's conditional formatting editor.

Users can add, remove and configure their own conditional formatting rules at runtime.

That means we don't need to create a custom rule editor, separate forms for the different rule types, or the logic required to maintain all those rules ourselves.

procedure TMainForm.ButtonEditRulesClick(Sender: TObject); 
begin 
  Grid.Root.ShowConditionalFormattingEditor; 
end;

This is where the low-code aspect becomes particularly valuable.

We're not simply enabling a visual effect with one line of code. We're exposing an entire configuration interface with it.

Configure Once, Use Again

After spending time configuring filters and conditional formatting, users probably don't want to recreate everything the next time they start the application.

So the sample also adds the ability to save the current configuration.

For conditional formatting, TTMSFNCDataGrid already provides serialization of its rules:

Grid.ConditionalFormatting.SaveToJSONStream(Stream);

The resulting JSON can later be loaded again with:

Grid.ConditionalFormatting.LoadFromJSONStream(Stream);

The sample stores the conditional formatting configuration in:

FNCDBReporterFormatting.json

For filtering, we can retrieve the current filter expression through:

Grid.Filter.FilterText

The sample stores this expression separately in:

FNCDBReporterFilter.ini

When the application starts again, the saved expression can be assigned back to the FilterBuilder:

Grid.FilterBuilder.FilterText := FilterText;

and applied:

Grid.RemoveFilter; Grid.ApplyFilter;

This gives us an easy way to restore a previously configured report view.

Save Your Report View

Together, these features introduce an interesting concept to our original report generator.

We're no longer just saving or exporting data.

We're allowing users to configure a view of that data.

For example, imagine a sales report where somebody:

1. Enables advanced filtering.
2. Filters the report to a particular region or product range.
3. Adds a conditional formatting rule to highlight high-value orders.
4. Adds another rule to draw attention to low-performing values.
5. Saves the configuration.

The next time the report is opened, that configuration can be restored and applied to the latest data.

The data may have changed, but the way the user wants to analyse it hasn't.

A Lot of Functionality, Very Little Code

This extension of the sample demonstrates something that is easy to overlook when looking at a feature list.

Adding filtering sounds simple until you have to create the filtering UI. Advanced filtering means operators, different value types and additional UI. Conditional formatting means defining rules, rendering them and preferably providing an editor. Saving those settings means serialization and restoration.

With TTMSFNCDataGrid, the core functionality is already available.

The essential calls are remarkably small:

// Filtering 
Grid.Options.Filtering.Enabled := True; 
// Advanced filtering 
Grid.Options.Filtering.Advanced := True; 
// Conditional formatting 
Grid.ConditionalFormatting.Enabled := True; 
// Open the rule editor 
Grid.Root.ShowConditionalFormattingEditor; 
// Save formatting 
Grid.ConditionalFormatting.SaveToJSONStream(Stream); 
// Load formatting 
Grid.ConditionalFormatting.LoadFromJSONStream(Stream);

This is the real advantage of the approach.

A few lines of Delphi code can expose functionality that would otherwise require complete interfaces and considerable application logic.

You remain in control of when and where the functionality is available, while TTMSFNCDataGrid takes care of most of the implementation.

From Static Report to Interactive Report

Our original project demonstrated how TTMSFNCDataGrid could be used as the foundation of a database report generator.

With these additions, that report becomes much more interactive.

Users can decide which information matters, narrow down larger datasets, visually identify interesting values and preserve their preferred configuration for later use.

And perhaps most importantly for us as Delphi developers, we didn't have to build all those systems from scratch.

Sometimes adding a powerful feature really can be just one line of code.

In the previous blog post, we introduced the new TTMSFNCFilterRulesManager and looked at how filtering can go beyond datasets and grid columns.

Instead of only filtering data, the Filter Rules Manager can evaluate properties of Delphi objects and use the result to change other properties or execute application logic.

We also showed the following example:

In this blog post, we're going to take a closer look at that example and see how it was built.

The application contains a TTMSFNCPlanner with several appointments and a search box at the top.

As the user types, appointments with a matching title keep their original appearance, while appointments that don't match are dimmed.

There is no dataset filter involved.

Instead, we're going to filter directly on the Title property of each TTMSFNCPlannerItem.

Setting Up the Planner

For this example, the Planner contains a number of appointments spread across the working week.

Adding an appointment is nothing special:

Item := TMSFNCPlanner1.Items.Add;
Item.Title := ATitle;
Item.Text := AText;
Item.StartTime := AStartTime;
Item.EndTime := AEndTime;
Item.Color := AFill;

Some examples used in the demo are:

• Team Standup
• Sprint Planning
• Architecture Review
• Design Review
• Product Demo
• Training Session
• Sprint Retrospective

What matters for our rule is that every appointment already has a Title property.

That's the property we're going to search.

Creating the Filter Rules Manager

We start by creating a TTMSFNCFilterRulesManager:

FRM := TTMSFNCFilterRulesManager.Create(Self);

Next, we need to connect the text entered by the user to our rule.

We could recreate the filter expression every time the user types something, but there is a better option: placeholders.

Adding a Dynamic Search Value

A placeholder lets a rule retrieve a value from another object when the rule is evaluated.

Our search text comes from a TEdit called SearchEdit.

We register its Text property as a placeholder:

FRM.AddPlaceholder(
  'Search',
  SearchEdit,
  'Text'
);

From this point on, we can use:

{Search}

inside our rule.

Whenever the rule is applied, {Search} is replaced with the current value of SearchEdit.Text.

This is an important detail: the value isn't fixed when the rule is created.

The same rule can therefore remain in place while the user continues typing.

Creating the Rule

Now we can create the actual rule:

FRule1 := FRM.AddRule(
  'SpotlightRule',
  TMSFNCPlanner1,
  'Items',
  '[Title] LIKE ''%{Search}%'''
);

This small piece of code contains most of the logic for our search.

Let's break it down.

1. The Rule Name

'SpotlightRule'

Every rule has a name so it can be identified later.

2. The Source

TMSFNCPlanner1

This is the object where the Filter Rules Manager starts.

But we don't want to evaluate the Planner itself. We want to evaluate its appointments.

That's where the next parameter comes in.

3. The Items Path

'Items'

The Filter Rules Manager uses this path to retrieve the collection of objects that should be evaluated.

In this example, that means every TTMSFNCPlannerItem inside:

TMSFNCPlanner1.Items

The rule is therefore applied to each appointment individually.

4. The Filter Expression

Finally, we have the actual condition:

'[Title] LIKE ''%{Search}%'''

This is where things become interesting.

Title is not a field from a dataset.

It is the Title property of TTMSFNCPlannerItem.

For every planner item, the Rules Manager retrieves that property and evaluates it using the filter expression.

If the user enters:

Team

the effective condition becomes:

[Title] LIKE '%Team%'

Appointments such as Team Standup match, while appointments such as Product Demo don't.

This is the key difference with the filtering examples from earlier in this series.

We're using the same structured filtering concepts, but now we're evaluating properties directly on Delphi objects.

What Should Happen When an Item Matches?

We now know whether each appointment matches the search.

The next question is what we want to do with that information.

We could hide appointments that don't match.

But for this example, we want to create more of a spotlight effect.

Matching appointments remain unchanged, while the other appointments are visually dimmed.

For that, we use CallBackAction:

FRule1.CallBackAction :=
  procedure(
    const ARule: TTMSFNCFilterRule;
    AItem: TObject;
    AIndex: Integer;
    const AMatched: Boolean)
  var
    Item: TTMSFNCPlannerItem;
    Idx: Integer;
  begin
    Item := AItem as TTMSFNCPlannerItem;
    Idx := Item.Index;

    if AMatched then
    begin
      Item.Color := FColors[Idx].Fill;
      Item.StrokeColor := FColors[Idx].Stroke;
      Item.FontColor := FColors[Idx].Font;
      Item.TitleFontColor := FColors[Idx].Font;
      Item.MarkColor := FColors[Idx].Mark;
      Inc(FMatchCount);
    end
    else
    begin
      Item.Color := DimColor(FColors[Idx].Fill);
      Item.StrokeColor := DimColor(FColors[Idx].Stroke);
      Item.FontColor := DimColor(FColors[Idx].Font);
      Item.TitleFontColor := DimColor(FColors[Idx].Font);
      Item.MarkColor := DimColor(FColors[Idx].Mark);
    end;
  end;

The callback is executed for every item processed by the rule.

The AMatched parameter immediately tells us whether the current planner item matched our Title condition.

When it matches, we restore its original colors.

When it doesn't, we apply a dimmed version of those colors.

One Match, Multiple Property Changes

This example also demonstrates another useful aspect of the Filter Rules Manager.

One condition can affect multiple properties.

For a non-matching appointment, we're changing:

• Color
• StrokeColor
• FontColor
• TitleFontColor
• MarkColor

All of these changes are driven by the result of a single condition:

[Title] LIKE '%{Search}%'

For this example we use a callback because we want precise control over several appearance properties and we also keep track of the number of matching items.

For simpler cases, the Filter Rules Manager also provides actions that can directly update properties without requiring a callback.

Making the Search Live

We have created the rule only once.

To turn it into a live search, all we need to do is reapply it when the text changes.

procedure TFormFilterRules.SearchEditChangeTracking(
  Sender: TObject);
begin
  UpdateFilter;
end;

The UpdateFilter method itself remains very small:

procedure TFormFilterRules.UpdateFilter;
begin
  FMatchCount := 0;

  FRM.ApplyRule(FRule1);

  CountLbl.Text := Format(
    '%d / %d',
    [FMatchCount, TMSFNCPlanner1.Items.Count]
  );
end;

Notice what isn't happening here.

We aren't:

• Iterating over the planner items ourselves.
• Reading every Title property manually.
• Rebuilding the filter expression.
• Copying the current search value into the rule.

We simply apply the existing rule again.

The Rules Manager resolves {Search} from SearchEdit.Text, iterates over the Planner items, evaluates their Title properties and calls the appropriate action.

What Happens When the Rule Is Disabled?

Because our rule changes the appearance of the Planner items, we also need to consider what should happen when the rule itself becomes inactive.

For that, we can provide an InactiveCallBackAction.

FRule1.InactiveCallBackAction :=
  procedure(
    const ARule: TTMSFNCFilterRule;
    AItem: TObject;
    AIndex: Integer)
  var
    Item: TTMSFNCPlannerItem;
    Idx: Integer;
  begin
    Item := AItem as TTMSFNCPlannerItem;
    Idx := Item.Index;

    Item.Color := FColors[Idx].Fill;
    Item.StrokeColor := FColors[Idx].Stroke;
    Item.FontColor := FColors[Idx].Font;
    Item.TitleFontColor := FColors[Idx].Font;
    Item.MarkColor := FColors[Idx].Mark;
  end;

When the rule is inactive, every appointment is restored to its original appearance.

This gives us three clear states:

• Match - keep the original appearance.
• No match - dim the appointment.
• Rule inactive - restore everything.

The Complete Rule Setup

If we remove the supporting UI and styling code, the actual rule setup is surprisingly compact:

FRM := TTMSFNCFilterRulesManager.Create(Self);

FRM.AddPlaceholder(
  'Search',
  SearchEdit,
  'Text'
);

FRule1 := FRM.AddRule(
  'SpotlightRule',
  TMSFNCPlanner1,
  'Items',
  '[Title] LIKE ''%{Search}%'''
);

FRule1.CallBackAction :=
  procedure(
    const ARule: TTMSFNCFilterRule;
    AItem: TObject;
    AIndex: Integer;
    const AMatched: Boolean)
  begin
    // Apply the matching or non-matching appearance here.
  end;

And when the search changes:

FRM.ApplyRule(FRule1);

That's the core of the example.

Not Just a Planner Feature

Although we're using TTMSFNCPlanner here, there is nothing Planner-specific about the rule itself.

The important ingredients are:

• An object that acts as the source.
• A path to the objects you want to evaluate.
• A property on those objects.
• A filter expression.
• An action to perform with the result.

In this example:

Source      : TMSFNCPlanner1
Items       : Items
Property    : Title
Condition   : LIKE '%{Search}%'
Action      : Highlight matching appointments

Change the source, item path and property, and the same approach can be used elsewhere in your application.

You could evaluate properties on visual controls, items in another FNC component, or your own Delphi objects.

Filtering Without Removing Anything

This example also shows why the term filtering becomes broader with the Filter Rules Manager.

Traditionally, filtering means that something either remains visible or disappears from the result.

Here, every appointment remains in the Planner.

The filter is simply being used to determine which rule should be applied to each item.

That result could change appearance, visibility, enabled state or another property. Or, as we've done here, it can be passed to custom application logic through a callback.

And because the condition can work directly with object properties such as Title, this isn't limited to traditional data filtering.

That's where TTMSFNCFilterRulesManager starts to become particularly useful: the filtering engine becomes a way to describe conditions throughout your application, while rules determine what should happen when those conditions are met.

When starting a new application, supporting multiple languages can easily end up somewhere near the bottom of the priority list. And when localization is added later to an existing or even long-running application, suddenly there are captions, messages, dialogs and other texts scattered all over the project that all need to be found, translated and kept in sync.

From a Real-World Need to TMS FNC Localization

For readers who have been following our blog, the name Erwin Denissen might already sound familiar.

Erwin is the developer behind FontCreator from High-Logic, which we featured earlier in one of our customer showcase blog posts. As part of his own software development, Erwin also ran into the challenges that come with adding and maintaining localization in an application.

Not finding a solution that matched the workflow he was looking for, he started building his own.

What began as a solution for his own needs eventually brought Erwin and TMS Software together. We saw a lot of potential in his work, and from that cooperation the project grew further into the product we are presenting today as TMS FNC Localization.

We want to explicitly thank Erwin for the work, ideas and experience he has contributed to making this possible!

Collect, Translate, Apply!

At its core, TMS FNC Localization is built around a straightforward workflow: collect the texts, translate them and apply the selected language. Instead of having to build the complete localization infrastructure yourself, you get dedicated components for each step!

Collect

The first challenge is finding everything that needs to be translated, especially in an existing application. The TTMSFNCLocalizationCollector helps gather localizable content from your application instead of forcing you to manually hunt down every caption and text property.

//Analyze and collect the application - only applies to live forms
TMSFNCLocalizationCollector.AnalyzeApplication;
//Analyze and collect a given form
TMSFNCLocalizationCollector.AnalyzeForm(Self);

Translate

Once the strings have been collected, they need to be managed and translated.

The TTMSFNCLocalizationEditor provides an easy way to work with the collected texts and the translations for the different languages. Opening the editor at runtime comes with the benefit of being able to see the translation changes immediately in your running application.

TMSFNCLocalizationEditor.Execute;

Alternatively, open it at design time from the context menu of the TTMSFNCLocalizationCollector or any TForm. When the editor is triggered at design time, you can also see which forms haven't been discovered yet!

What if you don't want to manually translate every item? Use the optional AI assistance to generate translations and you'll only need to verify the results! We've added support for a variety of AI services that you can use with your API key. These include OpenAI, Claude, Gemini, Grok, Mistral and DeepSeek. If you prefer local models, we have you covered via Ollama and llama.cpp.

Would you rather leave it to a professional? XLIFF export and import support is available, allowing you to outsource the work to professional translators using their own tools!

To help keep translations reliable, TMS FNC Localization comes with built-in automatic text validation for format specifiers, placeholders, accelerator keys, line breaks and whitespace, whether translations are entered manually, imported or generated with AI. It supports plural-aware translations as well, allowing the correct wording to be used depending on the quantity being displayed. This is especially useful for languages where pluralization rules go beyond a simple singular-versus-plural distinction.

On top of editing and verifying the translations, the TTMSFNCLocalizationEditor also lets you manage the list of languages you want to support, along with a set of exclusion rules for what should not be collected. Using the editor also means collection happens automatically, no need for additional code!

The editor keeps the translation process separate from the application itself. Adding another language or updating an existing translation becomes a matter of maintaining the localization data instead of changing forms or source code.

Apply

Finally, the TTMSFNCLocalizationLocalizer takes care of applying the selected language to the application! Point it to the folder where the localization files live, and calling the simple TrySetLocale method will immediately switch to the target language. This gives you fine control over when and how a language is set. If you'd rather hand that choice to your users, TMS FNC Localization ships with a ready-made language picker, TTMSFNCLocalizationCombobox, that you can drop straight into your forms!

Together, these components turn localization into a repeatable workflow instead of a one-off solution. When another language needs to be added later, you can simply repeat the same step again!

New or Existing, Localization Fits

Of course, the easiest moment to think about localization is before writing the first line of an application. From the start, you can keep your strings in one place with TTMSFNCLocalizationStringCatalog. That way you can keep everything organized, central and easy to collect.

That said, one of the goals behind TMS FNC Localization is to make localization approachable not only for new projects, but also for applications that already exist. Localization no longer has to be an all-or-nothing decision made on day one. You can introduce it gradually and grow it as the application grows.

Get Started with the BETA

TMS ALL-ACCESS users can start experimenting with TMS FNC Localization today! The BETA is available through TMS Smart Setup, making it easy to add the product to your development environment and keep up with new BETA versions as they become available.

To help you get started, we have included demos with the installation and prepared documentation covering both the component API and the overall workflow. Click here to open it on our new TMS Documentation site, the new home for all TMS product documentation.

Help Us Shape TMS FNC Localization

Localization requirements can differ significantly between applications, and feedback from developers using the product on real projects is extremely valuable.

If you are an ALL-ACCESS user, we encourage you to put it to work! Try it on a new application or, even better, try it on that older project that someone has just decided needs to conquer three new markets. Let us know what works well, what could work better and what is missing from your localization workflow!

Feedback and findings can be shared with us through the dedicated TMS Support Center category. We are looking forward to seeing what you build with it and in how many languages!

TMS FNC UI Pack 7.3

TMS FNC Data Grid 2.0

Intro

A grid can contain every answer and still make the important ones hard to find. Which sales representatives are leading the quarter? Which targets are at risk? Where is growth slowing down? Traditionally, answering those questions visually meant writing custom drawing events and maintaining the same business logic in several places.

With TMS FNC UI Pack 7.3, we are releasing TMS FNC Data Grid 2.0 and introducing a new declarative conditional-formatting engine for TTMSFNCDataGrid.

Conditional formatting lets the data decide how a cell or row should look. Add rules for values, text, dates, rankings, averages, duplicates or complete expressions, and the grid automatically applies fills, font styles, color scales, data bars and icon sets while it renders.

From Raw Values to Instant Insight

The new ConditionalFormatting property owns a collection of rules. Each rule defines three things:

• where it applies;

• when it matches;

• how the matching cell or row should be presented.

Rules are evaluated automatically as the grid paints, and remain effective when users scroll, sort or filter. There is no need to repeat the same decisions in OnGetCellLayout or a custom drawing event.

The engine includes ten rule families:

• cell-value comparisons;

• text matching;

• date conditions;

• top and bottom rankings;

• above- and below-average rules;

• unique and duplicate values;

• two- and three-color scales;

• data bars;

• icon sets;

• custom expressions.

Start with One Line

The convenience methods make common formatting rules deliberately small. To highlight every value below 100 in the Quota % column:

with TMSFNCDataGrid1.ConditionalFormatting.AddCellValueRule(
  COL_QUOTA, gfcLess, '100') do
  Appearance.Font.Color := gcRed;

ConditionalFormatting.Enabled is enabled by default, so the rule takes effect immediately.

Color Scales: See the Range

A color scale turns a numeric column into a compact heat map. The lowest, middle and highest values receive the selected colors, with the colors in between calculated automatically.

TMSFNCDataGrid1.ConditionalFormatting.AddColorScale(
  COL_SALES,
  gcRed,
  gcYellow,
  gcLimegreen);

This is useful for sales, margins, temperatures, scores or any other measurement where relative position matters as much as the number itself.

Data Bars and Icon Sets: Compare at a Glance

Data bars show magnitude directly inside a cell while keeping the original value visible. Icon sets divide values into recognizable bands using arrows, traffic lights, stars, flags and rating symbols.

// Compare quota attainment with proportional bars.
TMSFNCDataGrid1.ConditionalFormatting.AddDataBar(
  COL_QUOTA, gcDodgerblue);

// Show the direction of growth with traffic lights.
TMSFNCDataGrid1.ConditionalFormatting.AddIconSet(
  COL_GROWTH, gisTrafficLights3);

// Turn customer satisfaction into a five-star signal.
TMSFNCDataGrid1.ConditionalFormatting.AddIconSet(
  COL_CSAT, gisStars5);

The minimum and maximum values can be detected automatically or defined as numbers, percentages or percentiles. Values can remain visible next to the bar or icon, or the visual can stand on its own.

Highlight the Rows That Matter

Some conditions should draw attention to a complete record. ApplyToEntireRow extends the appearance of a matching rule across the row while the condition itself remains tied to one column.

with TMSFNCDataGrid1.ConditionalFormatting.AddTopBottomRule(
  COL_SALES, rkTop, 5) do
begin
  Priority := 10;
  ApplyToEntireRow := True;
  Appearance.Fill.Color := gcLightgoldenrodyellow;
  Appearance.Font.Style := [TFontStyle.fsBold];
end;

This example highlights the five best sales results without calculating or updating a threshold manually.

Expressions Across Columns

For decisions that depend on more than one value, expression rules use the same expression language as the Data Grid filter builder. Column names can be combined into a readable condition that is evaluated for each row.

with TMSFNCDataGrid1.ConditionalFormatting.AddExpressionRule(
  '([Growth %] < 0) AND ([Quota %] >= 100)') do
begin
  ApplyToEntireRow := True;
  Appearance.Fill.Color := gcMistyrose;
  Appearance.Font.Color := gcRed;
end;

This makes it easy to reveal combinations that deserve attention: growth declining despite reaching quota, stock falling below the reorder level, an overdue task that is still open, or a customer whose health indicators disagree.

Combining Rules with Priority

Conditional formatting becomes especially useful when several rules work together. A sales column can use a color scale, a quota column can show data bars, growth can display an icon set, and status can apply text-based colors—all in the same grid.

When rules overlap, a lower Priority number has higher precedence. The first matching rule claims the appearance aspects it sets, while later rules can still contribute aspects that remain unset. StopIfTrue can stop evaluation of the rules that follow it.

This gives you predictable layering without moving presentation logic into paint handlers.

A Visual Editor for VCL and FireMonkey

Not every formatting rule needs to start in code. TMS FNC Data Grid 2.0 includes a visual conditional-formatting editor for VCL and FireMonkey at design time.

The editor lets you:

• add, duplicate, delete and reorder rules;

• choose a rule type and its scope;

• select columns by name;

• configure comparisons, values and expressions;

• select fills, text colors, borders and font styles;

• configure color-scale bounds, data bars and icon sets;

• preview the selected rule before accepting it.

The rule collection is stored with the grid, so design-time configuration becomes part of the form just like the grid's other properties. Desktop applications can also open the same workflow at runtime with ShowConditionalFormattingEditor.

Cross-Framework by Design

The conditional-formatting engine is available in TTMSFNCDataGrid for VCL, FireMonkey and TMS WEB Core. The visual editor is available for VCL and FireMonkey, while the same rule collection and fluent helper methods can be configured in code on all three frameworks.

That means the formatting logic can travel with your application instead of being rewritten for each UI framework.

Installing TMS FNC UI Pack 7.3

TMS FNC UI Pack 7.3 is available through the modern Smart Setup based installation workflow:

tms self-update
tms install tms.fnc.*

If you are moving from the classic installers, uninstall older TMS FNC UI Pack installations from the previous setup flow first. This keeps IDE paths and package registrations clean.

You can learn more about TMS FNC UI Pack on the product page.

Conclusion

Conditional formatting in TMS FNC Data Grid 2.0 turns visual data analysis into a reusable part of the grid configuration. From one-line threshold rules to color scales, rankings, icon sets and expressions across multiple columns, the new engine makes important values stand out without custom painting code.

Together with the visual editor and the fluent runtime API, TMS FNC UI Pack 7.3 gives developers a faster way to build grids that do more than display data—they explain it.

Throughout this series, we've looked at different ways of building and applying filters.

We started with the TTMSFNCFilterBuilder, moved on to visual filter dialogs, and then used TTMSFNCFilterView to let users build filters naturally through controls in the application.

Until now, the result of a filter was mainly used to answer one question:

Does this item match the filter?

With the new TTMSFNCFilterRulesManager, we can take that answer and do something with it.

Instead of only filtering data, a matching expression can now change a property, show or hide controls, enable or disable functionality, or execute your own application logic.

From Filters to Rules

The easiest way to understand the Filter Rules Manager is to look at a rule as three parts:

• Where? - Which objects should be evaluated?
• When? - Which filter condition should match?
• What? - What should happen when it matches?

For example:

For all employees
where Country = 'Belgium'
set Visible = True

Or:

For all controls
where Name starts with 'btn'
set Visible = False

The filter itself is still handled by the same filtering logic we've introduced throughout this series.

The difference is that we now attach one or more actions to the result.

A First Rule

Let's start with a small example.

Suppose we have a panel containing several controls and only want controls whose name starts with btn to be visible.

With the Filter Rules Manager, this can be expressed in one rule:

mgr.AddRuleStartsWith(
  'ShowActionButtons',
  pnlControls,
  'Controls[*]',
  'Name',
  'btn',
  False
).AddVisibilityAction;

There is quite a lot happening in only a few lines, so let's break it down.

The Source

Every rule starts with a Source.

The source is the object from which the Filter Rules Manager starts looking for the items it should process.

In our example, that is:

pnlControls

But the source itself does not necessarily have to be the object we want to change.

Instead, we can navigate from the source to other objects in the source using an ItemsPath.

The ItemsPath

For our panel example, the ItemsPath is:

Controls[*]

This tells the Filter Rules Manager to process all controls belonging to the panel.

The * indicates that every item in the collection should be evaluated.

So our rule now effectively says:

For every control inside pnlControls...

If the ItemsPath is left empty, the rule can also be applied directly to the Source itself.

This makes rules useful for both individual objects and collections of objects.

The Filter

Next, we need to decide when the rule matches.

In our example, we evaluate the Name property:

Name starts with 'btn'

Internally, the rule uses TTMSFNCFilterBuilder to evaluate this expression.

This is important because it means the Filter Rules Manager isn't introducing another expression language.

The same operators and structured filtering concepts from the earlier parts of this series are reused here.

You can create a rule using one of the helper methods, as we did above, or provide filter text directly.

Rule.FilterText := 'Name LIKE ''btn%''';

More complex expressions can also be used, including combinations of multiple conditions.

The Action

So far, we know which objects we are processing and which ones match.

Now comes the new part: what should happen?

In our example, we added:

AddVisibilityAction

This changes the Visible property depending on whether the item matches the filter.

A matching control becomes visible, while a non-matching control becomes hidden.

The complete rule can therefore be read almost as a sentence:

mgr.AddRuleStartsWith(
  'ShowActionButtons',
  pnlControls,
  'Controls[*]',
  'Name',
  'btn',
  False
).AddVisibilityAction;

For all controls on this panel, find the controls whose Name starts with "btn", and set their visibility accordingly.

Actions Are Not Limited to Visibility

AddVisibilityAction is a convenient shortcut, but actions are not limited to the Visible property.

An action can target another property using an RTTI path.

Conceptually, an action consists of:

• A target property
• A value when the filter matches
• Optionally, a value when it doesn't match
• Optionally, a value when the rule is inactive

For example:

Rule.AddAction(
  'Enabled',
  True,
  False
);

A matching item will have Enabled set to True, while a non-matching item will have it set to False.

There are also convenience methods for common scenarios:

Rule.AddVisibilityAction;
Rule.AddEnableAction;
Rule.AddDisableAction;

And because the target is a property path, actions can go beyond simple top-level properties.

This opens the door to changing appearance and other properties based on filter conditions as well.

Multiple Actions on One Rule

A rule isn't limited to one action either.

Once an item matches, multiple properties can be changed as part of the same rule.

For example, a rule could make an item visible and enable it at the same time:

Rule
  .AddVisibilityAction
  .AddEnableAction;

This keeps the condition in one place.

You don't need to evaluate the same expression several times just because multiple things should happen when it matches.

Rules Can Be Active or Inactive

Every rule has an Active property.

This gives you an easy way to switch behavior on or off.

mgr.Rules[0].Active := not mgr.Rules[0].Active;
mgr.Rules[0].Apply;

When a rule is active, its filter is evaluated and the match or no-match actions are applied.

When it is inactive, the rule can use an InactiveValue instead.

This is useful when disabling a rule should also restore the objects to a known state.

So an action can effectively have three outcomes:

• Match - the item matches the filter.
• No match - the item doesn't match.
• Inactive - the rule itself is disabled.

Rules on Your Own Objects

The Filter Rules Manager is not limited to visual FNC controls.

One of the more interesting use cases is applying rules to your own Delphi objects.

Suppose we have an employee object:

TEmployee = class(TComponent)
private
  FName: string;
  FCompany: string;
  FCity: string;
  FCountry: string;
  FVisible: Boolean;
published
  property Name: string read FName write FName;
  property Company: string read FCompany write FCompany;
  property City: string read FCity write FCity;
  property Country: string read FCountry write FCountry;
  property Visible: Boolean read FVisible write FVisible;
end;

We can then create a rule that evaluates these objects and writes the result directly to their Visible property.

FManager
  .AddRuleStartsWith(
    'NameFilter',
    FEmployees,
    'Items[0..*]',
    'Name',
    'A'
  )
  .AddVisibilityAction;

When the rule is applied, the manager iterates over the employees, evaluates the Name property and updates Visible.

Your application can then decide how that property is used.

A grid could display only visible employees, for example, without the Filter Rules Manager needing to know anything about that grid.

Dynamic Rules with Placeholders

So far, the values in our rules have been fixed.

But application rules are often based on values that change at runtime.

This is where placeholders become useful.

A placeholder connects part of a rule to a property on another object.

For example, suppose we have a search edit:

FManager.AddPlaceholder(
  'SearchText',
  EditSearch,
  'Text'
);

We can then use that value inside the rule:

{SearchText}

Every time the rule is applied, the current value of EditSearch.Text is used.

This means the rule doesn't have to be recreated whenever the search text changes.

Even the Field Can Be Dynamic

Placeholders are not limited to filter values.

They can also be used in other parts of the rule, including the field being filtered.

For example, imagine a ComboBox where the user selects whether to search by Name, Company, City or Country.

We can first retrieve the selected index:

FManager.AddPlaceholder(
  'SearchFieldComboIndex',
  SearchFieldCombo,
  'ItemIndex'
);

Then use that index to retrieve the selected field:

FManager.AddPlaceholder(
  'FilterField',
  SearchFieldCombo,
  'Items[{SearchFieldComboIndex}]'
);

And finally use both placeholders in the rule:

FManager
  .AddRuleStartsWith(
    'EmployeeFilter',
    FEmployees,
    'Items[0..*]',
    '{FilterField}',
    '{SearchText}'
  )
  .AddVisibilityAction;

The same rule can now search different properties without being rebuilt.

Change the ComboBox, enter another search value, call Apply, and the current values are resolved automatically.

Applying the Rules

Once the rules have been configured, they can be applied through the manager:

FManager.Apply;

The manager processes its rules and, for each rule:

• Resolves the source and item path.
• Resolves any placeholders.
• Builds the filter.
• Evaluates the filter against every item.
• Determines whether the item matches.
• Applies the corresponding actions.

A rule can also be applied individually:

FManager.Rules[0].Apply;

This is useful when only one particular rule needs to be refreshed.

What If an Action Is Not a Property?

Not every action can be expressed as setting a property.

Sometimes you need to execute application-specific code.

For those situations, rules also support callbacks.

The callback receives the rule, the current item, its index and whether it matched.

This gives you the structured rule evaluation while leaving the final behavior completely up to your application.

There are also manager events available when you need more control over whether a rule or item should be processed, or when you want to override the resulting match.

For most common cases, however, property actions keep the implementation much simpler and avoid unnecessary event handlers.

Counting Matches Without Applying Actions

Sometimes you only want to know how many items currently match a rule.

For that, a rule provides CountMatchingItems.

Count := Rule.CountMatchingItems;

This evaluates the filter without writing the action values to the objects.

It can be useful for previews, counters or showing the user how many items a rule will affect before applying it.

Why a Filter Rules Manager?

Of course, all of this could also be written manually.

You could iterate over a collection, write several if statements, change properties and repeat that logic whenever the application state changes.

But as the number of conditions grows, that logic quickly becomes spread throughout the application.

The Filter Rules Manager brings those pieces together:

• The condition is represented by a filter.
• The objects to evaluate are defined by a source and item path.
• The result is connected to one or more actions.
• Runtime values can be supplied through placeholders.
• The complete rule can be enabled, disabled and reapplied.

Instead of writing:

if Employee.Country = 'Belgium' then
begin
  Employee.Visible := True;
  Employee.Enabled := True;
end
else
begin
  Employee.Visible := False;
  Employee.Enabled := False;
end;

The condition and its effects become a reusable rule.

Where Can This Be Used?

The Filter Rules Manager isn't specifically a grid filtering component or a UI visibility component.

It is deliberately more generic.

Some examples include:

• Show or hide controls depending on application state.
• Enable actions only when certain conditions are met.
• Change the appearance of matching items.
• Apply rules to collections of your own objects.
• Highlight records requiring attention.
• Control which application actions are currently available.
• Apply multiple property changes from a single condition.

And because the logic is based on the same filtering foundation used throughout this series, you don't need to learn another way of describing conditions.

From Filtering Data to Application Logic

This is ultimately the idea behind TTMSFNCFilterRulesManager.

A filter doesn't necessarily have to mean:

"Remove everything that doesn't match."

It can simply describe a condition:

"When this matches, do this."

By separating the condition from the action, the same structured filtering logic can be used in many more places throughout an application.

And because rules can work with component properties as well as your own objects, the Filter Rules Manager isn't tied to one particular control or use case.

It takes the FilterBuilder we've been using throughout this series and turns it into a more general rules system for Delphi applications.

Model Context Protocol (MCP) is the standard that lets AI clients like Claude Desktop, ChatGPT, Cursor, ... call out to your own tools. An MCP server exposes a set of functions, the assistant reads their descriptions, decides when to call them, and feeds the results back into the conversation.

As long as that server only talks to itself on your own machine, it doesn't need to ask "who's calling?" The moment it becomes a real server instead — reachable over the network, used by a colleague, or connected to from Claude Desktop on someone else's computer — that question matters a lot.

You've actually already answered that question dozens of times, just not for MCP. Every time you click "Continue with Google" or "Sign in with Microsoft" on some website, a login screen pops up, you approve it, and you're dropped back into the app, now connected. That familiar dance is called OAuth, and it's exactly the mechanism MCP uses to let an AI assistant connect to your server safely.

In this post we build that mechanism in Delphi. No prior knowledge of OAuth required — we'll explain each piece in plain terms as we go, then show the real, compiling Delphi code behind it.

• It's the same well-known approach used by "Sign in with Google" and every other app you've connected an account to — not something custom or proprietary.
• Turning it on for an existing MCP server is a one-line switch, not a rewrite.
• It's been tested against real AI assistants — MCP Inspector, Claude Desktop and ChatGPT have all connected through this exact code.

The two servers involved

There are two separate pieces at play here, and keeping them separate is the whole point.

One is your actual MCP server — the one with the tools the AI wants to call. The other is a small login and permissions service, whose only job is to check who someone is and hand out a token proving it. Your MCP server never checks logins itself; it just asks the login service, every time, "is this token still good, and what's it allowed to do?"

Two separate services; your MCP server trusts nothing it hasn't just double-checked with the login service.

Turning it on

If you already have an MCP server built with the TMS MCP SDK, requiring a login is not a rewrite. It's a handful of lines on the transport you already created.

Transport := TTMSMCPStreamableHTTPTransport.Create(nil, 8934, '/mcp');
Transport.RequireBearerAuthentication := True;
Transport.AuthorizationServers.Add(AuthorizationServerIssuer);
Transport.ResourceScopesSupported.Add('demo:read');
Transport.ResourceScopesSupported.Add('demo:write');
Transport.RequiredScopes.Add('demo:read');
Transport.OnValidateAccessToken := Handlers.ValidateAccessToken;

Server.Transport := Transport;

RequireBearerAuthentication := True is the actual switch: every request now needs a valid token attached, or it's refused. AuthorizationServers tells your server which login service to trust, and ResourceScopesSupported lists the permissions that exist (here, "read" and "write" access to a notes list) — both get automatically announced to any AI client that asks, so nothing needs to be configured by hand on the client side.

The one piece the SDK deliberately leaves to you is OnValidateAccessToken: the actual check of "is this token real, and what does it allow?" Different login services hand out tokens in different formats, so that decision is yours, not the transport's.

Checking a token: always ask, never assume

Here is the demo's real implementation of that check. It calls the login service and asks it directly, rather than trying to verify the token by itself.

procedure TDemoAuthHandlers.ValidateAccessToken(Sender: TObject; const AToken, AResourceURI: string;
  var AValidation: TTMSMCPAccessTokenValidation);
var
  Http: TIdHTTP;
  ReqBody, RespBody: TStringStream;
  Json: TJSONObject;
  Audience: string;
begin
  AValidation.Valid := False;

  Http := TIdHTTP.Create(nil);
  ReqBody := TStringStream.Create('token=' + TTMSMCPUtils.URLEncode(AToken));
  RespBody := TStringStream.Create;
  try
    Http.Request.ContentType := 'application/x-www-form-urlencoded';
    Http.Post(AuthorizationServerIssuer + '/introspect', ReqBody, RespBody);

    Json := TJSONObject.ParseJSONValue(RespBody.DataString) as TJSONObject;
    if not Assigned(Json) or not Assigned(Json.GetValue('active')) or
      not (Json.GetValue('active') as TJSONBool).AsBoolean then
      Exit; // not valid - AValidation.Valid stays False

    // Make sure this token was actually meant for THIS server, not some
    // other one the same login service happens to protect.
    Audience := '';
    if Assigned(Json.GetValue('aud')) then
      Audience := Json.GetValue('aud').Value;
    if Audience <> AResourceURI then
      Exit; // valid token, but issued for a different server - reject anyway

    AValidation.Valid := True;
    AValidation.Subject := Json.GetValue('sub').Value;
    AValidation.Scopes := Json.GetValue('scope').Value.Split([' ']);
  finally
    RespBody.Free; ReqBody.Free; Http.Free;
  end;
end;

That middle check — confirming the token was actually meant for this server — matters more than it looks. Without it, a token handed out for some other server (that happens to share the same login service) would be accepted here too, just because it was technically "still valid". Checking who a token was meant for is what stops it from being reused somewhere it was never supposed to work.

Put together, every single request runs through the same short checklist before a tool ever gets called:

Every call is double-checked with the login service before a tool ever runs.

What it looks like in Claude Desktop

All of the above is what makes this work under the hood. Here's what it actually looks like from the other side, adding this server to Claude Desktop as a custom connector — and it will look familiar, because it's the same "sign in and approve" pattern as any other app.

Add the connector's address and hit Connect. Approve on the sign-in screen that opens, and the connector shows connected:

Before — not yet connected

After — approved and connected

In between sits the sign-in screen itself — plain HTML, served straight from the Delphi backend, no client-side JavaScript involved:

The sign-in screen: plain server-rendered HTML, nothing exotic needed to make this part work.

The permissions you approve here decide what a token is allowed to do. Claude adds its own, separate layer of consent on top of that, per tool, before it will actually use anything:

Claude's own tool-permission setting, independent of what you approved during sign-in.

Two separate checks, worth keeping apart: the sign-in step decides what a token is entitled to at all; Claude's own permission setting decides whether it will actually use a given tool right now without asking first. Approving "write" access during sign-in doesn't mean Claude will silently add a note — that second decision stays entirely with Claude, on your machine.

From demo to a real deployment

Both servers ship two ways: as plain console apps you can run and read top to bottom in an afternoon, and as installable Windows services (a proper install command, a config file, a log file to check) for when you actually want one sitting on a server.

We ran that exact path start to finish: built as Windows services, put behind IIS on a real domain with a real certificate, and connected end to end by MCP Inspector, Claude Desktop and ChatGPT — sign in, approve, and a live tool call, all the way through.

That last stretch — going from "it works on my own machine" to "it works on a real server, for anyone" — has its own sharp edges: what address the server needs to tell clients about once it's behind a proxy, a place where the sign-in step can get silently misdirected by proxy configuration, and a couple of real bugs we found and fixed along the way. We wrote all of that down separately, in detail, rather than compress it into a footnote here: see the documentation for the full setup-to-production walkthrough.

Why this matters

• Requiring a login is a one-line switch on the server you already have, not a rewrite of your tools.
• AI clients need no manual setup to connect — the whole sign-in process is standard and already understood by MCP-aware clients, the same way "Sign in with Google" already works everywhere without you configuring anything.
• Your MCP server trusts nothing by default; every token is checked with the login service, every time, and checked against being reused on the wrong server.
• The demo login service is built to be strict by default — it won't redirect anywhere it hasn't been explicitly told is safe.
• The same code that runs as a five-minute local demo is the code we actually deployed on a real server with a real domain — this isn't a toy that stops working the moment it leaves your own machine.

Get the demo

All four projects — the two console demos and their Windows-service counterparts — are in the distribution folder under Demos/OAuth Authorization Server Demo, Demos/OAuth Resource Server Demo, Demos/OAuth Authorization Server Service and Demos/OAuth Resource Server Service.

For everything past "it runs on my machine" — turning these into installable services, adding a certificate, and putting them behind IIS on a real domain, caveats included — the documentation walks through that in the order you'd actually run into each decision.

Clone it, point a client at it, and watch the whole sign-in happen without writing a single line of client-side authentication code.

TMS AI Studio is the complete toolkit for bringing AI and the Model Context Protocol to your Delphi applications. Build MCP servers and clients, connect Claude and other assistants to your own tools and data, and add cloud AI to your VCL and FMX apps — all in native Delphi. Discover TMS AI Studio.

Exporting a GPX file through the device share sheet

procedure TCityGuide.BtnShareClick(Sender: TObject);
var
  LFileName: string;
  FName: string;
begin
  if UILogic.City <> '' then
    FName := UILogic.City + '.gpx'
  else
    FName := 'mycitytour.gpx';

  LFileName := TPath.Combine(
    TPath.GetTempPath,
    TPath.GetFileName(FName)
  );

  UILogic.ExportToGPX(TMSFNCMaps, LFileName);

  ShareFile(LFileName, 'application/xml', FName);
end;

LIntent := TJIntent.Create;
LIntent.setAction(TJIntent.JavaClass.ACTION_SEND);
LIntent.setType(StringToJString(AMimeType));

LIntent.putExtra(
  TJIntent.JavaClass.EXTRA_STREAM,
  TJParcelable.Wrap((LUri as ILocalObject).GetObjectID)
);

LIntent.addFlags(
  TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION
);

TAndroidHelper.Activity.startActivity(
  TJIntent.JavaClass.createChooser(
    LIntent,
    StrToJCharSequence(ATitle)
  )
);

LURL := TNSURL.Wrap(
  TNSURL.OCClass.fileURLWithPath(
    StrToNSStr(AFilePath)
  )
);

LItems := TNSMutableArray.Create;
LItems.addObject((LURL as ILocalObject).GetObjectID);

LActivity := TUIActivityViewController.Wrap(
  TUIActivityViewController.Alloc.initWithActivityItems(
    LItems,
    nil
  )
);

LRootVC.presentViewController(LActivity, True, nil);

ShareFile(
  '/path/to/citytour.gpx',
  'application/xml',
  'Share city tour'
);

Converting AI-generated descriptions into speech

procedure TUILogic.Speak(Description: string);
begin
  FCloudAIAudio.Speak(Description, 1, 'nova');
end;

FCloudAIAudio := TCloudAI.Create(Self);
FCloudAIAudio.Service := aiOpenAI;
FCloudAIAudio.OnSpeechAudio := SoundReady;

FMP3Player := TStreamMP3Player.Create;

procedure TUILogic.SoundReady(
  Sender: TObject;
  HttpStatusCode: Integer;
  HttpResult: string;
  SoundBuffer: TMemoryStream
);
begin
  FMP3Player.Play(SoundBuffer);
end;

Playing an MP3 stream with FireMonkey

1. It creates a unique filename using a GUID.
2. It writes the stream to TPath.GetCachePath.
3. It assigns that temporary file to TMediaPlayer.
4. It starts playback.
5. It destroys the media player before deleting the temporary file.

FMP3Player.Play(SoundBuffer);

procedure TStreamMP3Player.Play(AStream: TStream);
var
  LFileName: string;
  LFileStream: TFileStream;
begin
  if not Assigned(AStream) then
    raise EArgumentNilException.Create('AStream');

  ReleaseMedia;

  LFileName := CreateTempMP3FileName;

  AStream.Position := 0;
  LFileStream := TFileStream.Create(
    LFileName,
    fmCreate or fmShareDenyWrite
  );
  try
    LFileStream.CopyFrom(AStream, 0);
  finally
    LFileStream.Free;
  end;

  FTempFileName := LFileName;
  FMediaPlayer.FileName := FTempFileName;
  FMediaPlayer.CurrentTime := 0;
  FMediaPlayer.Play;
end;

Conclusion

• Isolate native platform APIs behind a common Delphi wrapper
• Use conditional compilation inside implementation units rather than throughout the UI
• Use secure sharing mechanisms such as Android FileProvider
• Use temporary and cache directories through System.IOUtils
• Handle asynchronous AI responses with events
• Adapt stream-based data to filename-based platform APIs
• Carefully manage native resources before deleting temporary files.

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.

Last week we launched our free Summer Project 2026: TMS City Guide, an AI-powered virtual tour guide built entirely with Delphi.

Instead of following a predefined route, TMS City Guide creates a personalized walking tour based on your location and interests. As you walk, the app introduces you to landmarks, hidden gems and historical locations, complete with AI-generated spoken descriptions directly from your smartphone.

If you missed the original announcement, you can read all about the project in our previous blog post.

See it in action

A demo is worth a thousand screenshots, so we took TMS City Guide for a real-world test in the beautiful city of Bruges.

Watch how the app generates a walking tour on the fly, navigates between points of interest and brings each location to life with AI-generated narration.

Everything is open source

Like our previous summer projects, the complete source code is available for free. Clone it, learn from it, extend it, or use parts of it in your own applications.

The full project is available on GitHub:

Built with TMS components

TMS City Guide showcases how easy it is to combine modern AI capabilities with native cross-platform Delphi development.

The application was built using:

• TMS FNC Maps for interactive mapping and routing
• TMS FNC UI Pack for the modern user interface
• TMS AI Studio for AI integration, speech generation and intelligent content

To celebrate this summer project, we're offering a 25% discount on these products until August 31, 2026.

Simply use coupon code during checkout to activate the discount.

Coming next: Behind the scenes

The application contains several interesting Delphi techniques that deserve a closer look.

In an upcoming blog post we'll explore how we implemented:

• Exporting generated walking tours as GPX files using the native operating system Share Sheet
• Generating and streaming AI-produced speech on the fly
• Bringing together AI, mapping and native FireMonkey development into one cross-platform application

If you're interested in the technical implementation, stay tuned—we'll dive into the source code soon.

Build it. Customize it. Share it.

You can clone the project from GitHub and build it yourself for iOS or Android using Delphi. If you'd rather get started immediately, a ready-to-use Android APK is also available in the repository.

To run the application you'll need:

• an OpenAI API key
• a Google Maps API key
• Delphi

Once you've created your own walking tours, we'd love to see them! Share the cities you've explored, the routes you've generated, or the improvements you've added. Who knows—your ideas might inspire the next version of TMS City Guide.

Happy coding—and happy exploring! 🌍🚶‍♂️