The installers for the TMS FNC product family are getting a major upgrade. Both trial and registered editions are moving to a new installation flow that is faster to set up, easier to maintain, and fully aligned with the latest RAD Studio target platforms.

This update applies across the full TMS FNC range, including TMS FNC AppTools, TMS FNC Blox, TMS FNC Chart, TMS FNC Cloud Pack, TMS FNC Core, TMS FNC Dashboard Pack, TMS FNC Gantt Chart, TMS FNC Grid Excel Bridge, TMS FNC Maps, TMS FNC Push Notifications, TMS FNC UI Pack, TMS FNC WebSocket, and TMS FNC WX Pack.

A modern installer experience

The new installers bring a consistent and streamlined setup experience across all TMS FNC products. Whether you are evaluating a trial or installing as a registered user, the process is now simpler and more predictable.

This transition also modernizes the underlying installer technology. It ensures compatibility with the latest RAD Studio versions and target platforms, including Windows on Arm (Arm64EC). The result is a smoother setup process and better alignment with modern development environments.

Installing TMS FNC products

Registered versions (via TMS Smart Setup)

All registered TMS FNC products are now available exclusively through TMS Smart Setup. Before installing, make sure to uninstall any classic installations via the Windows control panel.

If you are new to TMS Smart Setup, consult the Smart Setup documentation to install the tms command-line tool. Once installed, you can install individual products with commands such as:

tms install tms.fnc.uipack
tms install tms.fnc.chart
tms install tms.fnc.core

This approach ensures you always have access to the latest versions with minimal effort.

Prefer a visual workflow? You can also manage installations through TMS Dashboard, a centralized interface for installing, updating, and maintaining all your TMS components.

Trial versions

Want to evaluate a TMS FNC product? Simply visit the product page of your choice, click Free Trial, enter your email address, and select your IDE.

The trial downloads immediately, and you will receive a trial key that can be entered during installation. This provides a quick and straightforward way to explore the capabilities of each component.

Moving forward

With this migration, the entire TMS FNC product family benefits from a cleaner installation experience, tighter integration with TMS Smart Setup, and improved support for modern multi-device development using Delphi and C++Builder.

This marks an important step in unifying installation and update workflows across the TMS ecosystem, following earlier updates to other product lines.

As always, your feedback is invaluable. Try the new installation flow for your TMS FNC products and let us know how we can continue improving the experience.

Almost every modern application offers it: a row of buttons that say "Continue with Google", "Sign in with Microsoft", or "Login with Apple". Users have come to expect it — they don't want yet another password to remember, and you don't want the liability of storing one. At the same time, corporate customers increasingly demand that your app authenticate against their identity provider, so employees use the same single sign-on they use for everything else.

Until now, wiring this up in a Delphi backend meant a lot of plumbing: redirect dances, PKCE, state and nonce handling, token validation, and the headache of mapping an external account to a user in your own database — repeated for every provider you wanted to support.

The next version of TMS Sphinx removes that plumbing. Sphinx can now act as an identity broker, delegating authentication to upstream providers like Google or Microsoft Entra while still issuing and controlling its own tokens, users and sessions.

A quick refresher on TMS Sphinx

TMS Sphinx is an OAuth 2.0 and OpenID Connect authentication and authorization server framework for Delphi. It lets you add secure, standards-based login to your own applications — desktop, web, mobile and APIs — with Sphinx acting as the identity provider that issues and validates tokens.

Your client applications already talk to Sphinx as their OpenID Connect provider. With identity brokering, that doesn't change at all. The new part happens entirely on the server side.

What is identity brokering?

An identity broker (also called an IdP proxy or identity federation) sits between your applications and one or more external identity providers:

• Your client apps keep talking only to Sphinx, exactly as before.
• Behind the scenes, Sphinx delegates the actual authentication to an upstream provider — Google, Microsoft Entra, a corporate IdP, even another Sphinx server.
• Sphinx receives the upstream result, maps that external identity to a local user, and completes the original request with its own Sphinx-issued tokens.

The key benefit: the tokens your applications receive are always issued and signed by Sphinx. The upstream tokens are used only to establish who the user is, and are then discarded (unless you explicitly choose to keep them). Your scopes, your claims, your sessions, your user database — all stay under your control.

This is exactly what you want when you need to:

• Offer familiar "Login with Google / Microsoft / GitHub / Apple / Facebook" buttons.
• Authenticate users against an existing corporate identity provider for a B2B customer.
• Support multi-tenant scenarios where different customers use different identity providers.
• Keep issuing your own tokens and managing your own users regardless of how people sign in.

Registering an upstream provider

Providers are registered in the new ExternalProviders collection of TSphinxConfig. You can add them at design time (double-click the ExternalProviders property) or from code. At a minimum you give the provider a unique name, the authority URL, and the client id/secret you registered for Sphinx at that provider:

  Provider := SphinxConfig1.ExternalProviders.Add;
  Provider.Name := 'google';
  Provider.DisplayName := 'Google';
  Provider.Authority := 'https://accounts.google.com';
  Provider.ClientId := 'your-client-id';
  Provider.ClientSecret := 'your-client-secret';
  Provider.Scope := 'openid email profile';
  Provider.AutoDiscover := True;

When AutoDiscover is True (the default), Sphinx fetches the provider's discovery document from Authority + "/.well-known/openid-configuration" to learn its endpoints automatically. The redirect URI you register at the upstream provider is always Sphinx's own callback endpoint, oauth/external/callback.

That's it. No manual handling of authorization codes, PKCE verifiers, state, nonce or token validation — Sphinx does all of it for you.

Adding "Login with..." buttons

To let the end user pick a provider on the Sphinx login page, just set ShowInLoginPage to True. Use DisplayName for the button text and IconUrl for the icon:

  Provider := SphinxConfig1.ExternalProviders.Add;
  Provider.Name := 'google';
  Provider.DisplayName := 'Google';
  Provider.IconUrl := 'img/providers/google.svg'; // a built-in icon
  Provider.ShowInLoginPage := True;
  // ... authority, client id/secret, scope as above

A nice touch: Sphinx ships ready-to-use, brand-colored icons for the most common providers, so you don't have to source and host them yourself. Just point IconUrl at one of the built-in relative paths:

The user clicks the button, authenticates at the provider's own consent screen, and comes right back — logged into your app.

Want a login page with no password form at all? Set LoginOptions.AllowPasswordLogin := False and the page shows only the provider buttons (with a safeguard that still shows the local form if no providers happen to be available, so you can't lock everyone out).

Delegating transparently (no buttons)

Sometimes you don't want the user to choose — you want a specific client, tenant or scope to always authenticate against a particular provider. The OnResolveExternalProvider event is the single decision point that turns brokering on for a request:

procedure TForm1.SphinxConfig1ResolveExternalProvider(Sender: TObject;
  Args: TResolveExternalProviderArgs);
begin
  // Transparently delegate every request to the corporate identity provider.
  Args.ProviderName := 'corporate-idp';
end;

Because the logic is entirely yours, you can delegate only for certain clients or tenants and fall back to the normal Sphinx login for everyone else. The user never sees a Sphinx login screen at all — they go straight to the corporate IdP and back.

Mapping the external user to a local user — without code

After the upstream login completes, Sphinx needs to know which local user that identity corresponds to. The recommended, durable key is the pair (provider, subject) — the provider name plus the stable sub claim, which (unlike an e-mail address) never changes. Sphinx persists this in a new link table via the TUserLogin entity.

For the common cases you don't have to write a single line of code. Just configure the new built-in reconciliation policy:

  // Link an external sign-in to an existing account by verified e-mail...
  SphinxConfig1.ExternalLoginOptions.AllowAutoLinkByEmail := True;
  // ...and create a brand-new local account on first sign-in.
  SphinxConfig1.ExternalLoginOptions.AllowAutoProvision := True;

With this, Sphinx automatically:

1. Resolves an existing link by (provider, subject).
2. If none, links to an existing user matching by verified e-mail.
3. If still none, provisions a new local user from the upstream profile.

All options default to off, so nothing happens automatically until you opt in. When a new user is created, the OnExternalUserProvisioned event fires so you can finish the account (assign roles, copy profile fields, etc.).

And if a provider doesn't return everything you require — Facebook, famously, returns no e-mail — Sphinx automatically shows a "complete your profile" step asking the user for the missing field, then continues. Again, no code on your part.

Full control when you need it

For everything else, the OnExternalSignIn event gives you complete control over the mapping. It receives convenient access to the subject, e-mail and verification status, plus a user manager bound to the current request:

procedure TForm1.SphinxConfig1ExternalSignIn(Sender: TObject;
  Args: TExternalSignInArgs);
var
  User: TUser;
begin
  // Resolve first by the durable link (provider + subject).
  User := Args.UserManager.FindByLogin(Args.ProviderName, Args.Subject);

  // First sign-in: match an existing account by e-mail and remember the link.
  if User = nil then
  begin
    if not Args.EmailVerified then
    begin
      Args.Reject('A verified email is required');
      Exit;
    end;
    User := Args.UserManager.FindByEmail(Args.Email);
    if User <> nil then
      Args.UserManager.AddLogin(User, Args.ProviderName, Args.Subject);
  end;

  Args.User := User;
end;

Built for the real world

A few details that show this is more than a demo feature:

• Multi-tenant Microsoft Entra works out of the box. When a provider's issuer is a {tenantid} template (as Entra returns for the organizations/common authorities), Sphinx resolves the placeholder with each token's tenant id before validating — so issuer validation stays enabled and secure, no workarounds needed.
• Two-factor authentication is respected. An external sign-in still honors the user's Sphinx 2FA configuration. Or, when the upstream already performed MFA, you can trust it and skip the second challenge with Args.SkipTwoFactor := True.
• You can keep the upstream tokens. Enable ExternalLoginOptions.SaveTokens and Sphinx persists the upstream access_token, refresh_token and id_token so your app can later call the provider's APIs on the user's behalf via GetAuthenticationToken.
• Security is built in. PKCE, state and nonce are generated and validated by Sphinx, the callback is bound to the originating browser with a single-use cookie, and client secrets never leave the server.

Try it in the Simple demo

The Simple demo server (demos/Simple/Server) ships a ready-to-fill template in ConfigureExternalProviders (MainForm.pas). Register the demo's callback URL, http://localhost:2001/tms/sphinx/oauth/external/callback, as an authorized redirect URI in the Google Cloud Console, drop in your own client id and secret, and a "Continue with Google" button appears on the login page. The demo's OnExternalSignIn handler resolves the user by link, falls back to e-mail, and provisions a local user on first sign-in — so the whole brokered flow works end to end.

Conclusion

Identity brokering brings one of the most-requested features in modern authentication to Delphi developers, with very little effort:

• Better user experience — familiar "Login with..." buttons and no extra passwords.
• Enterprise-ready — authenticate against corporate identity providers and multi-tenant Entra.
• You stay in control — Sphinx always issues its own tokens and owns your users, scopes and sessions.
• Less code — automatic reconciliation, provisioning and profile completion mean common scenarios need almost no code at all.

To dive deeper, read the full Identity brokering documentation and the release notes, and learn more about TMS Sphinx on its product page.

TMS FNC UI Pack 7.2

Intro

In many applications, a grid is more than a table on a form. It can represent different views of the same workflow: a summary, a sales overview, an inventory list, a log, or a temporary working set. Traditionally, switching between those views often means clearing and rebuilding the grid, copying data around, or keeping multiple grid controls alive.

In TMS FNC UI Pack 7.2, TTMSFNCDataGrid adds a powerful new way to handle this with TTMSFNCDataGridRendererSource and the grid's RendererSource property.

A renderer source acts as a complete standalone grid layer. It contains its own renderer, its own data, its own appearance and its own state. Assigning that source to a grid makes the grid render that layer by reference.

What RendererSource Does

The new RendererSource property lets one TTMSFNCDataGrid switch between different prepared renderer layers. Each layer can have different columns, rows, data, styling and scroll behavior.

Setting RendererSource to nil uses the grid's own built-in renderer and data. Assigning a TTMSFNCDataGridRendererSource switches the grid to that external layer.

• One grid, multiple layers: switch between complete grid states without rebuilding the grid from scratch.

• Layer-specific data: each renderer source keeps its own cells, rows and columns.

• Layer-specific appearance: each source can have its own colors, selection style and layout settings.

• Live by reference: the grid does not copy the layer; edits are made on the active renderer source.

• State preservation: when you switch away from a layer and return later, that layer still has its own data and state.

  
  

Preparing Renderer Layers

The included demo prepares two external renderer sources: a blue Sales by Region layer and a green Product Inventory layer. Each source owns its own Renderer.

private
  FSalesLayer: TTMSFNCDataGridRendererSource;
  FInventoryLayer: TTMSFNCDataGridRendererSource;

procedure TFormRendererSource.FormCreate(Sender: TObject);
begin
  SeedGridOwnData;

  FSalesLayer := TTMSFNCDataGridRendererSource.Create(Self);
  FSalesLayer.Name := 'SalesLayer';
  BuildSalesLayer;

  FInventoryLayer := TTMSFNCDataGridRendererSource.Create(Self);
  FInventoryLayer.Name := 'InventoryLayer';
  BuildInventoryLayer;
end;

The grid starts with its own built-in layer. The external layers are prepared up front, but they are not shown until they are assigned to the grid.

Sales by Region

The first renderer source uses a blue theme and contains regional quarterly sales data. The grid switches to this layer without changing the grid control itself.

procedure TFormRendererSource.BuildSalesLayer;
var
  r: TTMSFNCDataGridRenderer;
begin
  r := FSalesLayer.Renderer;
  r.BeginUpdate;
  try
    r.CellAppearance.FixedLayout.Fill.Color := gcSteelblue;
    r.CellAppearance.FixedLayout.Font.Color := gcWhite;
    r.CellAppearance.NormalLayout.Fill.Color := gcAliceblue;
    r.CellAppearance.SelectedLayout.Fill.Color := gcLightsteelblue;
    r.Options.Column.Stretching.Enabled := True;

    r.FixedRowCount := 1;
    r.ColumnCount := 6;
    r.RowCount := 6;

    r.Cells[0, 0] := 'Region';
    r.Cells[1, 0] := 'Q1';
    r.Cells[2, 0] := 'Q2';
    r.Cells[3, 0] := 'Q3';
    r.Cells[4, 0] := 'Q4';
    r.Cells[5, 0] := 'Total';
  finally
    r.EndUpdate;
  end;
end;

Product Inventory

The second renderer source uses a green theme and contains product inventory data. It has a different column layout, different values and different styling, but it is still displayed through the same grid.

procedure TFormRendererSource.BuildInventoryLayer;
var
  r: TTMSFNCDataGridRenderer;
begin
  r := FInventoryLayer.Renderer;
  r.BeginUpdate;
  try
    r.CellAppearance.FixedLayout.Fill.Color := gcSeagreen;
    r.CellAppearance.FixedLayout.Font.Color := gcWhite;
    r.CellAppearance.NormalLayout.Fill.Color := gcHoneydew;
    r.CellAppearance.SelectedLayout.Fill.Color := gcDarkseagreen;
    r.Options.Column.Stretching.Enabled := True;

    r.FixedRowCount := 1;
    r.ColumnCount := 5;
    r.RowCount := 7;

    r.Cells[0, 0] := 'Product';
    r.Cells[1, 0] := 'SKU';
    r.Cells[2, 0] := 'In Stock';
    r.Cells[3, 0] := 'Reorder Level';
    r.Cells[4, 0] := 'Status';
  finally
    r.EndUpdate;
  end;
end;

Switching Layers

Once the layers are prepared, switching the grid is just a property assignment:

procedure TFormRendererSource.btnSalesClick(Sender: TObject);
begin
  TMSFNCDataGrid1.RendererSource := FSalesLayer;
end;

procedure TFormRendererSource.btnInventoryClick(Sender: TObject);
begin
  TMSFNCDataGrid1.RendererSource := FInventoryLayer;
end;

procedure TFormRendererSource.btnDefaultClick(Sender: TObject);
begin
  TMSFNCDataGrid1.RendererSource := nil;
end;

This makes it possible to build dashboards, inspectors, drill-down views and alternate data views while keeping the UI simple: one visible grid, multiple prepared renderer layers.

Editing the Active Layer

The grid facade always targets the active layer. If the sales layer is active, grid edits affect the sales renderer source. If the inventory layer is active, edits affect the inventory renderer source. When the grid is using its own built-in renderer, edits affect the grid's own data.

procedure TFormRendererSource.btnAddRowClick(Sender: TObject);
var
  newRow: Integer;
begin
  TMSFNCDataGrid1.BeginUpdate;
  try
    newRow := TMSFNCDataGrid1.RowCount;
    TMSFNCDataGrid1.RowCount := newRow + 1;
    TMSFNCDataGrid1.Cells[0, newRow] := Format('Added row %d', [newRow]);
  finally
    TMSFNCDataGrid1.EndUpdate;
  end;
end;

Because each renderer source keeps its own state, changes remain with that layer even after switching to another layer and back.

Where This Helps

RendererSource is especially useful when an application needs to reuse the same grid area for different kinds of information:

• Dashboards: switch between summary, sales and inventory views.

• Master-detail screens: show different detail grids without creating multiple visible controls.

• Data inspectors: keep separate layouts for different object types.

• Temporary working views: let users edit a layer and return to it later with its state intact.

  
  

Installing TMS FNC UI Pack 7.2

TMS FNC UI Pack 7.2 is also available through the modern installation workflow. As described in the modernized installer blog post, TMS is moving product installation to the newer Smart Setup based flow.

tms self-update

tms install tms.fnc.*

If you are migrating from classic installers, first uninstall older TMS FNC UI Pack installations from the previous setup flow before installing through Smart Setup. This keeps the IDE paths, package registrations and product folders clean.

Conclusion

RendererSource in TTMSFNCDataGrid adds a clean way to work with multiple complete grid layers from a single visible grid. Each layer can keep its own data, appearance and state, while the grid can switch between them with one assignment.

For applications that need flexible data views, dashboards or context-sensitive grids, TMS FNC UI Pack 7.2 makes the architecture simpler and the user experience smoother.

• Windows VCL applications
• FireMonkey desktop applications on Windows and macOS
• Native FireMonkey mobile applications on iOS and Android
• Linux FireMonkey applications
• TMS WEB Core web client application
  
  

The source is available in this repository and on GitHub:

Architecture: Thin Platform Units Around A Shared Core

The implementation in the FNC folder follows a clean pattern. There are framework-specific units such as:

• FNC\VCL.TMSFNCBarCode.pas
• FNC\FMX.TMSFNCBarCode.pas
• FNC\WEBLib.TMSFNCBarCode.pas
• FNC\VCL.TMSFNCQRCode.pas
• FNC\FMX.TMSFNCQRCode.pas
• FNC\WEBLib.TMSFNCQRCode.pas

These units bring in the appropriate graphics, control, and utility classes for each framework, but the functional implementation is shared through common include files:

{$I TMSFNCBarCodeCommon.inc}

and

{$I TMSFNCQRCodeCommon.inc}

This is a very effective use of the TMS FNC Core abstraction layer. Platform-specific adaptation stays thin, while the generation logic, rendering behavior, and export features remain centralized. That reduces duplication, keeps behavior aligned across frameworks, and makes the code base significantly easier to evolve.

For Delphi developers, that is the real payoff: framework neutrality without giving up the native component model.

Why This Is Especially Relevant For FireMonkey

The FireMonkey angle deserves special attention. Once the barcode and QR code logic is implemented against TMS FNC Core, the same components can flow naturally into FMX applications, including native mobile applications.

That means developers can use the same code base not only in desktop applications, but also in iOS and Android apps built with FireMonkey. For scenarios such as inventory, ticketing, event check-in, field services, healthcare workflows, or retail companion apps, that is a very compelling proposition: no separate mobile-specific barcode generation library is needed.

The Hosted TMS WEB Core Demo

The technical story becomes even more convincing when there is a live browser deployment thanks to TMS WEB Core showing the exact same component model at work. That is what the demo with full source code under FNC\Demo provides, and the hosted version is available here:

https://www.tmssoftware.com/site/webcore/barqrcodes

Below is a capture of the hosted demo:

This is not a mock-up. It is a real TMS WEB Core application using the FNC-based barcode and QR code components in the browser. The demo does not rely on elaborate setup code. It starts a standard web form and lets the components do the work.

The main form, implemented in FNC\Demo\Umainform.pas, contains:

• a page control with separate QR code and barcode tabs
• a TTMSFNCQRCode component
• a TTMSFNCBarCode component
• text input controls for QR and barcode content
• a combobox for selecting barcode symbologies
• export buttons for SVG and PNG

The QR code tab exposes free text entry and live rendering, while the barcode tab exposes both a value field and a barcode type selector.

Demo Code: Direct And Practical

The QR code update path is intentionally straightforward:

procedure TForm1.WebEdit1Change(Sender: TObject);
begin
  TMSFNCQRCode1.Text := WebEdit1.Text;
end;

As the user edits the text, the QR code component updates immediately. That is the kind of direct event-driven programming model Delphi developers expect, and the browser deployment preserves it.

The barcode side follows the same pattern:

procedure TForm1.WebEdit2Change(Sender: TObject);
begin
  TMSFNCBarCode1.Value := WebEdit2.Text;
end;

Here too, the component API stays simple. A value property is assigned, and the visual result updates accordingly.

Barcode type selection

The demo also contains a small but useful layer around barcode type selection. A local enum lists the supported barcode types, and the form populates the combobox at startup:

procedure TForm1.WebFormCreate(Sender: TObject);
var
  BarcodeType: TTMSBarcodeType;
begin
  for BarcodeType := Low(TTMSBarcodeType) to High(TTMSBarcodeType) do
    WebComboBox1.Items.Add(TMSBarcodeTypeName(BarcodeType));

  WebComboBox1.ItemIndex := 1;
  WebPageControl1.ActivePageIndex := 0;
end;

When the selection changes, the demo assigns a format-appropriate sample value:

procedure TForm1.WebComboBox1Change(Sender: TObject);
var
  BarcodeType: TTMSBarcodeType;
begin
  BarcodeType := TTMSBarcodeType(WebComboBox1.ItemIndex);
  TMSFNCBarCode1.Value := SampleValue(BarcodeType);
  WebEdit2.Text := TMSFNCBarCode1.Value;
end;

Barcode formats can be slighly different for different barcode types. So supplying a valid sample content per barcode type makes the demo more useful. 

Export To SVG And PNG

The export story is another strong point because it shows that the component is not limited to on-screen rendering. The demo exposes both SVG and PNG export from the same form.

SVG export:

procedure TForm1.WebButton1Click(Sender: TObject);
begin
  if WebPageControl1.ActivePageIndex = 0 then
    TMSFNCQRCode1.SaveToSVG('qrcode.svg');

  if WebPageControl1.ActivePageIndex = 1 then
    TMSFNCBarCode1.SaveToSVG('barcode.svg');
end;

PNG export:

procedure TForm1.WebButton2Click(Sender: TObject);
begin
  if WebPageControl1.ActivePageIndex = 0 then
    TMSFNCQRCode1.SaveToPNG('qrcode.png');

  if WebPageControl1.ActivePageIndex = 1 then
    TMSFNCBarCode1.SaveToPNG('barcode.png');
end;

One Technical Investment, Many Targets

The broader point of the FNC implementation is clear. By coding against TMS FNC Core, the library is no longer boxed into a VCL-only story. The same underlying implementation can be surfaced in:

• classic Windows desktop applications
• cross-platform FireMonkey desktop applications
• native FireMonkey mobile applications
• browser-based TMS WEB Core applications

That is a strong technical result with a clear business benefit. You invest in one code base, one API style, and one component model, then reuse it across the places where your users actually are.

If you want to inspect the code, the GitHub repository is here:

https://github.com/tmssoftware/Bar_QRCodes4D

If you want to see it running immediately, try the hosted demo here:

https://www.tmssoftware.com/site/webcore/barqrcodes

We hope you enjoy integrating QR and bar code creation in your Delphi apps, be it VCL apps, FireMonkey cross-platform apps or web client applications created with TMS WEB Core. We are eager to learn what other libraries you want to have available in the FNC concept. Let us know and we'll investigate.

In the previous blog post, we looked at why filtering can become difficult when everything is handled as a string.

A filter like this is simple enough:

Age > 18

But once you start combining multiple conditions, adding brackets, switching between AND and OR, validating field names, and converting values to the right type, it becomes harder to keep everything under control.

That is where the TTMSFNCFilterBuilder comes in.

From Filter Text to Filter Structure

The idea behind the FilterBuilder is simple:
Instead of building one long filter string manually, we build the filter as a structure.

The starting point for this structure is the Filter property.

FilterBuilder.Filter

This filter contains the expressions and groups that define the filtering logic.

Every filter expression consists of three parts:

• The field or column name
• The comparison operator
• The value to compare against

For example:

Age > 18

Can be represented as:

• Field: Age
• Operator: feoLargerThan
• Value: 18

By storing these parts separately, the filter becomes easier to build, inspect, validate, and eventually convert into filter text. It also avoids a lot of fragile string concatenation. Instead of manually writing operators such as > or =, you work with predefined operators such as feoLargerThan and feoEqual.

Building Expressions

The smallest building block of a filter is an expression.

An expression describes a single condition.

FilterBuilder.Filter.AddExpression('Age', feoLargerThan, 18);

Notice that we are not building a string here. We are simply describing the filter logic.

At this point, the FilterBuilder doesn't care whether the final output will be used for a TDataSet, OData, a universal filter expression, or a completely custom format.

Combining Expressions with Groups

Most filters contain multiple conditions.

For example:

Age > 18 AND Country = 'BE'

The FilterBuilder combines expressions through groups.

The root filter itself is already a group and has its own group operator.

FilterBuilder.Filter.GroupOperator := fgoAND;

Every expression that is added to this filter is automatically combined using AND.

If needed, you can simply change the operator to OR.

FilterBuilder.Filter.GroupOperator := fgoOR;

Nested Groups

The real strength of this approach becomes apparent when more complex filters are required.

Consider the following example:

(Age > 18 AND Country = 'BE') OR (Age > 21 AND Country = 'US')

Writing this manually isn't too difficult, but maintaining it quickly becomes harder as more conditions are added.

With the FilterBuilder, you simply create two groups.

var
  BelgiumGroup,
  USGroup: TTMSFNCFilterBuilderGroup;
begin
  FilterBuilder.Filter.GroupOperator := fgoOR;

  BelgiumGroup := FilterBuilder.Filter.AddGroup;
  BelgiumGroup.GroupOperator := fgoAND;
  BelgiumGroup.AddExpression('Age', feoLargerThan, 18);
  BelgiumGroup.AddExpression('Country', feoEqual, 'BE');

  USGroup := FilterBuilder.Filter.AddGroup;
  USGroup.GroupOperator := fgoAND;
  USGroup.AddExpression('Age', feoLargerThan, 21);
  USGroup.AddExpression('Country', feoEqual, 'US');
end;

Every group can contain:

• Expressions
• Other groups
• Its own AND or OR operator

Because groups can contain other groups, filters can be nested indefinitely without manually keeping track of brackets.

Generating Filter Text

Once the filter structure has been created, generating the filter text becomes trivial.

ShowMessage(FilterBuilder.FilterText);

For the nested example above, the generated filter text would be similar to:

(Age > 18 AND Country = 'BE') OR (Age > 21 AND Country = 'US')

The FilterBuilder generates the complete expression, including operators and brackets.

When the selected format matches the syntax expected by a TDataSet, the generated text can immediately be assigned to the dataset.

FilterBuilder.FormatType := fftDelphiDataSet;

DataSet.Filter := FilterBuilder.FilterText;
DataSet.Filtered := DataSet.Filter <> '';

In other words, the FilterBuilder doesn't replace Delphi's filtering mechanism—it simply provides a much safer and easier way to generate the filter text.

Parsing Existing Filter Text

The process also works in reverse.

If you already have filter text that follows one of the supported formats, the FilterBuilder can parse it back into its internal structure.

if FilterBuilder.ParseExpression('Age > 18 AND Country = ''BE''') then
begin
  // The filter text was parsed successfully
end;

This allows existing filters to be visualized, modified, validated, or reused without having to recreate them manually.

Of course, parsing depends on the selected formatting rules. The expression text needs to follow the configured syntax and format type in order to be parsed successfully. When the expression is not valid, ParseExpression returns False. And you have an event available to have a calculated quess where the error might be.

Supporting Different Filter Formats

One of the biggest advantages of separating the filter structure from the generated text is that the output format can easily be changed.

The same filter logic can be used for multiple targets.

For example, a Delphi DataSet filter doesn't use the same syntax as an OData filter.

Changing the output is simply a matter of selecting another format.

FilterBuilder.FormatType := fftOData;
FilterText ==> (Age gt 18 and Country eq 'BE') or (Age gt 21 and Country eq 'US')

The available format types are:

• fftDelphiDataSet for Delphi DataSet filter syntax
• fftUniversalFilterExpressions used in the TMS FNC DataGrid
• fftOData for OData query syntax
• fftCustom for a fully customized parse format

This means you only build the filter once, while the FilterBuilder generates the appropriate output for the destination.

Matching Data Without Filter Text

Generating filter text is only one way of using the FilterBuilder.

Sometimes you don't want to apply a filter string at all.

For example, when working with custom controls, collections of objects, or any data that isn't connected to a TDataSet, you can validate the data directly against the filter structure.

Before validating rows, the builder needs to know which data columns are available and in which order values will be supplied.

FilterBuilder.AddDataColumn('Age', fdtNumber);
FilterBuilder.AddDataColumn('Country', fdtText);

This can then be used with ValidateFilterRow.

var
  Values: TTMSFNCFilterValidateInputRow;
  Match: Boolean;
begin
  SetLength(Values, 2);

  Values[0] := 25;
  Values[1] := 'BE';

  Match := FilterBuilder.ValidateFilterRow(Values);
end;

The values are matched against the configured data columns. In this example, the first value is compared with Age, while the second value is compared with Country.

If the current filter is:

Age > 18 AND Country = 'BE'

The row above will match because 25 is larger than 18 and the country value is BE.

This allows you to use exactly the same filtering logic regardless of where your data is stored.

You decide what should happen when the data matches.

• Show or hide rows
• Highlight matching records
• Filter object collections
• Implement your own filtering logic

If you're working with multiple rows, you can validate the complete dataset in a single call.

ResultArray := FilterBuilder.ValidateFilterArray(InputArray, True);

This returns an array of Boolean values indicating which rows satisfy the filter. The second parameter controls how the input array is organized. When it is set to True, the input array is treated as row-based data.

Several FNC controls use this functionality internally, but it is equally useful in your own applications where no built-in filtering mechanism exists.

Why This Matters

By separating the filter logic from the generated filter text, the FilterBuilder offers several advantages:

• You no longer build complex filter strings manually.
• The generated filter text can be assigned directly to a TDataSet.
• Existing filter text can be parsed back into a structured model.
• Nested groups become much easier to create and maintain.
• The same filter can generate different output formats.
• You can validate data directly without relying on a specific component.

The FilterBuilder forms the foundation for all filtering components in the FNC framework.

Whether you want to generate filter text, parse existing expressions, validate data, or build a visual filtering interface, everything starts with this structured filter model.

Next Step

Now that we've built a structured filter model, it's time to make it easier to use.

In the next blog post, we'll take a look at the TTMSFNCFilterDialog, which uses the FilterBuilder internally to let users create complex filters through a visual interface—without ever having to write a filter expression themselves.

Intro

Exporting charts is not only about taking a screenshot. Reports, dashboards, documentation, and web pages often need output that stays sharp at any size. This post shows how TMS FNC Chart exports a professional mixed chart to SVG across FMX, VCL and WEB using the same core approach: render the chart through ITMSFNCGraphicsExport into TTMSFNCGraphicsSVG.

Quick Highlights

• One export flow works across FMX and VCL with framework-specific units and the same chart export concept.

• TTMSFNCGraphicsSVG captures the chart as real SVG output, preserving paths, text, markers, labels, and annotations.

• The sample combines an area series, bar series, and line series in one dashboard-style chart, making the export visually rich enough for real-world use.

Building a Mixed Chart for Export

The sample builds a regional revenue dashboard with three coordinated series: operating profit as an area chart, revenue as colored bars, and the plan as a line with markers. This gives the SVG export a representative mix of filled shapes, strokes, labels, markers, legend items, and annotations.

ProfitSerie := FChart.Series.Add;
ProfitSerie.LegendText := 'Operating profit';
ProfitSerie.ChartType := ctArea;
ProfitSerie.AutoYRange := arCommonZeroBased;
ProfitSerie.YValues.Positions := [ypLeft];
ProfitSerie.XValues.Positions := [xpBottom];
ProfitSerie.XGrid.Visible := True;
ProfitSerie.YGrid.Visible := True;

RevenueSerie := FChart.Series.Add;
RevenueSerie.LegendText := 'Revenue';
RevenueSerie.ChartType := ctBar;
RevenueSerie.Labels.Visible := True;
RevenueSerie.Labels.Format := '%.0f';

TargetSerie := FChart.Series.Add;
TargetSerie.LegendText := 'Plan';
TargetSerie.ChartType := ctLine;
TargetSerie.Stroke.Width := 3;
TargetSerie.Markers.Visible := True;

Each revenue bar receives its own color through MakeGraphicsColor, while the line series adds markers and an annotation to demonstrate that detailed chart elements are included in the SVG output.

Highlight: SVG export is especially useful for mixed charts because text, grid lines, markers, bars, and annotations stay crisp in documentation, reports, and web pages.

Configuring the Chart Presentation

The chart is configured with a white background, subtle axis colors, a top-right legend, and a clear title. The goal is to make the exported file immediately usable in a report or presentation without extra styling.

FChart.Fill.Color := gcWhite;
FChart.Stroke.Color := MakeGraphicsColor(205, 214, 222);
FChart.Title.Text := 'Regional Revenue, Profit and Plan';
FChart.Title.Height := 56;
FChart.Title.Font.Size := 20;
FChart.Title.Font.Color := MakeGraphicsColor(27, 49, 76);

FChart.Legend.Visible := True;
FChart.Legend.Position := lpTopRight;
FChart.Legend.Fill.Color := gcWhite;
FChart.Legend.Font.Color := gcDarkslategray;

FChart.XAxis.Positions := [xpBottom];
FChart.YAxis.Positions := [ypLeft];

The same visual setup is used in the FMX and VCL demos, so the exported result remains consistent across frameworks.

Exporting the Chart to SVG

The actual export is compact. The chart implements ITMSFNCGraphicsExport, so the sample creates a TTMSFNCGraphicsSVG instance with the chart dimensions, starts an SVG scene, and asks the chart to export itself into that graphics context.

SVG := TTMSFNCGraphicsSVG.Create(ExportWidth, ExportHeight);
try
  SVG.BeginScene;
  try
    Exporter := FChart as ITMSFNCGraphicsExport;
    Exporter.Export(SVG, RectF(0, 0, ExportWidth, ExportHeight));
  finally
    SVG.EndScene;
  end;

  TFile.WriteAllText(FileName, SVG.Build, TEncoding.UTF8);
finally
  SVG.Free;
end;

The SVG.Build call returns the complete SVG document as text. From there, the result can be written to disk, downloaded in a browser, embedded in HTML, or passed into another document generation workflow.

Highlight: The chart is not converted to a bitmap first. The export path writes vector output directly through the FNC graphics abstraction.

Output

The SVG is saved to the user's documents folder and then opened with the system default SVG viewer. This makes the demo easy to run and easy to inspect.

function TFormExportSVG.ExportFileName: string;
begin
  Result := TPath.Combine(TPath.GetDocumentsPath,
    'TMSFNCChart_SVG_Export.svg');
end;

TFile.WriteAllText(FileName, SVG.Build, TEncoding.UTF8);
TTMSFNCUtils.OpenFile(FileName);

The resulting file is plain SVG and can be opened in a browser, inserted into documentation, edited in a vector graphics tool, or embedded directly into a web page.

Conclusion

TMS FNC Chart makes SVG export a straightforward Delphi workflow: build the chart, create TTMSFNCGraphicsSVG, export through ITMSFNCGraphicsExport, and save the result. The same pattern works across FMX, VCL and WEB, making it easy to deliver sharp, scalable chart output from desktop and web applications.

TMS FNC Maps has been a cornerstone of cross-platform mapping in Delphi and C++ Builder for several years now, and with the release of v4.6, the API integrations for all major mapping service providers have been brought up to date. Before diving into what changed, this post is also a good opportunity to take a step back and look at everything TMS FNC Maps offers: especially for developers who are just getting started or are looking to get more out of their existing setup.

What is TMS FNC Maps?

TMS FNC Maps is a cross-framework, cross-platform and cross-service mapping component library for Delphi and C++ Builder. The core idea is simple but powerful: you should never be locked in to a single mapping provider. Switching between mapping services requires nothing more than changing a single property: no code changes, no component swaps, no rewrites.

The library currently supports the following mapping services:

Google Maps	Here Maps	Microsoft Azure Maps
MapBox	Leaflet	OpenLayers
Apple MapKit	TomTom	OpenStreetMap Nominatim
OpenRouteService	GeoApify

TMS FNC Maps targets VCL, FireMonkey and TMS WEB Core and runs on Windows, macOS, iOS, Android and all major browsers. Write your mapping code once and deploy it everywhere.

Feature highlights

Markers, shapes and overlays

Add markers, polylines, polygons, circles and rectangles to any map with just a few lines of code. Custom styled HTML/JavaScript overlays allow you to design fully interactive elements that sit on top of the map. Marker clustering is supported for Google Maps and OpenLayers, keeping your maps clean when displaying large datasets.

Directions and routing

The TTMSFNCDirections component provides route calculation across multiple providers. Travel modes include car, bicycle, walking, public transport and truck (where supported by the provider). Waypoints, optimized ordering and step-by-step turn instructions are all available, and results can be displayed directly on the map.

Geocoding and reverse geocoding

TTMSFNCGeoCoding handles address-to-coordinate and coordinate-to-address lookups across all supported providers. Switching providers for geocoding is, again, just a property change.

GPX and GeoJSON support

TMS FNC Maps includes built-in support for importing and exporting GPX and GeoJSON files. This makes it straightforward to visualize routes from fitness trackers, navigation devices or any other standard source.

Static maps

The TTMSFNCStaticMap component retrieves a static map image for a given location, zoom level and map type. The resulting image can be displayed using the companion TTMSFNCMapsImage component. Useful for reports, thumbnails or any context where an interactive map is not required.

Additional data components

• TTMSFNCTimeZone: retrieves timezone information for a coordinate
• TTMSFNCTollCost: calculates toll costs along a route with per-segment detail 
• TTMSFNCElevation: retrieves elevation data for a path or set of coordinates
  
  

Custom tile servers

For OpenLayers and Leaflet, custom tile servers can be configured. This opens up use cases with private mapping infrastructure, satellite imagery providers or specialist geographic data services.

News

Mapping providers do not stand still. They continuously release new API versions with improved endpoints, tighter security requirements and better data quality, while phasing out older versions. Keeping TMS FNC Maps aligned with these changes is essential to ensure your applications keep working reliably.

In TMS FNC Maps v4.6, the following service integrations have been updated:

• HERE Maps: updated to v3.2 
• MapBox: updated to v3.24.0
• Azure Maps: updated to v4
• OpenLayers: updated to v10.9

TTMSFNCGoogleMaps always uses the latest available Google Maps JavaScript API version automatically. If needed, a specific API version can be assigned manually to pin your application to a known-good version.

All other supported services have also been reviewed and confirmed compatible with their current API endpoints.

These are behind-the-scenes updates. Existing code using TMS FNC Maps requires no changes. Simply update to v4.6 and your application will automatically benefit from the current API integrations across all providers.

Resources

There is a wealth of material available to help you get the most out of TMS FNC Maps.

Documentation

• Full online documentation is available, it covers getting started, component reference and code examples. 
• API key setup for each provider explains how to register your application so you can obtain an application key 
  
  

Blog posts

A large number of dedicated blog posts covering TMS FNC Maps have been published on the TMS Software blog, ranging from first steps to advanced topics. A few highlights:

• Comparing mapping services in TMS FNC Maps for Delphi
  a practical guide to choosing the right mapping service for your application
• Comparing directions services in TMS FNC Maps for Delphi
  an in-depth look at the directions services supported across providers
• Comparing geocoding services in TMS FNC Maps for Delphi
  a side-by-side comparison of geocoding capabilities per service
• Using Consistent and Customizable Markers in TMS FNC Maps
  how to go beyond default marker icons with fully custom styles
• Visualize your routes with TMS FNC Maps
  a practical project using Google StreetView and GPX route data
• Simplify Mapping Across Platforms with TMS FNC Maps
  a broad overview of combining mapping services

Browse all TMS FNC Maps blog posts here.

Videos

A growing library of video tutorials covering TMS FNC Maps is available on the TMS Software videos page. Highlights include:

• Maps with Delphi using TMS FNC Maps 
  an extensive multi-part series by César Cardoso (Code4Delphi) covering installation, setup, practical examples and more
• Gjalt's 101: Find your way in TMS FNC Maps
  a beginner-friendly introduction
• TMS FNC Maps: Support for Leaflet
  a walkthrough of integrating Leaflet for Windows and web applications
• Fixing Google Maps API Errors in Delphi Applications with TMS FNC Maps 
  learn how to fix Google Maps API errors in Delphi applications with this quick guide
  
  

Book

For a deep dive, the book Hands-on with Delphi: FNC Maps by Holger Flick is available on Amazon. It covers the component library in detail with practical examples and is highly recommended for anyone looking to build serious mapping applications.

Discover the book on Amazon

Support

If you have any questions or run into anything after updating, the dedicated TMS FNC Maps support category is the right place to go.

Getting the update

TMS FNC Maps v4.6 is available now. All license holders, including TMS ALL-ACCESS and TMS FNC Component Studio subscribers, can install the update directly via TMS Smart Setup.

Not yet a customer? Discover TMS FNC Maps and start with a free trial.

Filtering data is something we all do.

Whether it’s a grid, a dataset, or a list of objects—at some point, users want to narrow things down.

In Delphi, the most common starting point is still the Filter property on a TDataSet.

DataSet.Filter := 'Age > 18 AND Country = ''BE''';
DataSet.Filtered := True;

It works.
But once you go beyond simple cases, it quickly becomes harder to manage.

Where It Starts to Break Down

The main issue is that filtering is just… a string.

That means:

• No structure
• No validation before execution
• No guidance while building it

And as developers, we might get away with that.
But even then, it’s not always pleasant to work with.

A slightly more complex example:

([YearOfBirth] < 2008 AND [Subscription Country] = 'BE') OR ([YearOfBirth] < 2005 AND [Subscription Country] = 'US')

Now imagine:

• Typing this manually
• Making sure field names are correct
• Keeping brackets balanced
• Debugging when something doesn’t work

There’s no help.
You only find out something is wrong after applying the filter.

What About End Users?

This is where things really fall apart.

We can’t realistically expect users to write expressions like that.

Even if we wrap it in a UI:

• They still need to understand field names
• They still need to understand operators
• They still need to think in syntax

That’s not how users think about filtering.

They think in terms of:

• “Show me adults”
• “Only items from Belgium”
• “Orders after this date”

Not:

(Age > 18 AND Country = 'BE')

The Core Problem

If you look at it from a bit of distance, the issue is not filtering itself.

It’s how we represent it.

Right now:

• We store logic as a string
• We build it manually
• We validate it too late

What we’re missing is:

• A structured way to define filters
• Something that reflects actual logic (not just text)
• A way to validate before applying

A Different Approach

Instead of thinking in strings, you can break a filter down into smaller parts:

• A field (what are we filtering on?)
• An operator (how do we compare?)
• A value (what are we comparing against?)

Something like:

Age > 18

Becomes:

• Field: Age
• Operator: >
• Value: 18

And once you have that, you can start combining them:

• With AND / OR
• In groups
• Even nested if needed

At that point, you’re no longer dealing with a string.
You’re working with a model of your filter logic.

And that opens the door to:

• Validation before execution
• Reusable logic across controls
• And eventually… user-friendly ways to build filters

Where This Leads

Once filtering is structured instead of string-based, a few things become possible:

• You can generate different output formats (DataSet, SQL, OData, …)
• You can validate filters safely before applying them
• You can build UI on top of the logic, instead of parsing text afterward

That’s the direction we started exploring.

Not by replacing filtering entirely,
but by putting a layer in between:
something that understands filter logic
and can translate it where needed

Next Step

In the next post, we’ll look at how this structured approach can be implemented in practice:

• how filters are built internally
• how grouping and nesting works
• and how this solves a lot of the issues mentioned here