Intro

Documentation is where most developers meet a component for the first time. It should be fast to browse, honest about what the control does, and easy to read at 8 a.m. or midnight. That is why we have rebuilt the TMS documentation from the ground up: a single, modern site with a consistent structure, real screenshots, full-text search, and code you can copy straight into a project.

The new site lives at doc.tmssoftware.com. Each product family is its own self-contained site, so TMS FNC UI Pack and every other product share the exact same look, navigation, and search — while still deploying independently.

What Is New

• One consistent structure: every product has an Overview, a Components catalog, Product Guides, Release Notes, and a full API Reference in the same order, so once you learn one product you know them all.

• Task-oriented guides: instead of a wall of property names, guides explain why and when to use a feature, with a runnable example for every workflow.

• Qt-style API reference: each class page shows unit family, inheritance, implemented interfaces, and grouped properties, methods and events — with inherited API separated from what the class itself declares.

• Light and dark themes: a single click switches the whole site, and the screenshots switch with it.

• Full-text search: instant results across guides, API and pages, faceted by type.

• Real, verified content: screenshots are captured from the live control, and code snippets are checked against the current source.

  
  

One Look, Light or Dark

Here is the same page — the TMS FNC UI Pack Data Grid landing page — in both themes. Notice the consistent frame: the product catalog on the left, breadcrumbs and content in the middle, an “In this article” outline on the right, and search plus the theme toggles in the top bar. The hero screenshot even follows the theme you pick.

Guides That Teach

Feature guides are the heart of the new docs. They open with the use case, explain the concepts, and back every workflow with a runnable snippet and a screenshot of the real UI state. The Data Grid Filtering guide, for example, walks from a one-line live search box all the way to Excel-style header dropdowns and advanced filter expressions — with a detailed outline so you can jump straight to the step you need.

And because setup-heavy workflows need more than a property table, every guide backs its explanation with a compilable snippet. Enabling the filter row with header filter dropdowns on the grid looks like this:

procedure TForm1.FormCreate(Sender: TObject);
begin
  TMSFNCDataGrid1.BeginUpdate;
  try
    TMSFNCDataGrid1.Options.Filtering.Enabled := True;
    TMSFNCDataGrid1.Options.Filtering.Row := True;
    TMSFNCDataGrid1.Options.Filtering.DropDown := True;
    TMSFNCDataGrid1.Options.Filtering.MultiColumn := True;
  finally
    TMSFNCDataGrid1.EndUpdate;
  end;
end;

Snippets like this are validated against the current source, so the property paths and call order stay correct as the product evolves.

Search Across Everything

Every family site ships with instant full-text search. Start typing and you get ranked results across guides, API members and pages, faceted by type — with keyboard navigation so you never have to reach for the mouse.

Finding Your Way Around

Each product overview offers two clear routes to the same information:

• By component: Overview â†' Components â†' the component landing page â†' its guides and API. Best when you know which control you need.

• By API: Overview â†' API Reference, grouped by component first rather than a flat alphabetical dump. Best when you are looking up a specific class or member.

Component guides live with the component, and cross-cutting topics (JSON persistence, SVG, getting started) live under Product Guides, so a page is always where you would expect it to be.

What Is Next

The new site currently focuses on the TMS FNC product family, which is where we started rolling out the new format. That is only the beginning.

Over the coming period we will be moving the remaining legacy documentation into the new system, including content that today lives in standalone PDF files. As each product is migrated, its guides, examples, and API reference will be rewritten to the same structure — consistent navigation, real themed screenshots, verified snippets, and full-text search — so the whole TMS catalog eventually shares one modern home instead of a mix of older sites and separate PDFs.

Conclusion

The new TMS documentation site is a consistent, searchable, theme-aware home for every product, built so that guides teach, screenshots reflect the real control, and code samples compile. The TMS FNC UI Pack Data Grid pages are a good place to start exploring the new format.

Visit doc.tmssoftware.com and browse the TMS FNC UI Pack section to see it in action.

In the previous blog post, we looked at how TTMSFNCFilterBuilder can be used to build filters as a structured model instead of manually creating one long filter string.

That structure gives us a lot of flexibility as developers.
But in many applications, the filter is not something the developer should define completely in code.

At some point, users need a way to create or change filters themselves.

And we probably don't want them to write something like this:

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

This is where the filter dialogs come in.

Visual Filtering

The idea is simple.

Instead of asking users to write filter text manually, we let them build the filter visually.

They select:

• the field they want to filter on
• the operator they want to use
• the value they want to compare with

The dialog then creates the filter structure internally and generates the correct filter text.

Because the dialog knows the type of each field, it can also limit the available operators to those that make sense for that field.

So a text field will not show the same operators as a number field, and a boolean field will not show operators that require a text value.

This means that operator mismatch errors are avoided before the filter is even created.

TTMSFNCDataSetFilterDialog

The easiest way to start is with TTMSFNCDataSetFilterDialog. This control is available in our TMS FNC UI Pack.

This dialog is specifically made for working with a TDataSet.

You can connect it to a dataset:

DataSetFilterDialog.DataSet := ClientDataSet1;

When the dialog is opened, it can use the dataset fields to determine which fields are available and which data type they have.

This makes the setup very small, while still giving the user a guided way to create a filter.

The generated result can be assigned directly to the dataset filter.

ClientDataSet1.Filter := DataSetFilterDialog.FilterText; ClientDataSet1.Filtered := ClientDataSet1.Filter <> '';

In most cases you don't even need to manually handle the generated filter text, because the dialog is designed to work directly with the dataset.

Editing Existing Filters

The dialog is not only useful for creating new filters.

If the dataset already has a filter text assigned, the dialog can parse it and rebuild the visual structure.

This makes it possible to open an existing filter, change it visually, and write the updated filter text back to the dataset.

So instead of replacing existing filtering logic, the dialog helps to make it easier to manage.

New: Design-Time Filter Editor

Since the latest release, TTMSFNCDataSetFilterDialog is also available as a design-time editor for the Filter property of a TDataSet.

This means you no longer need to type the filter text manually in the Object Inspector.

You can open the visual filter dialog, select the fields, operators and values, and let the editor generate the filter text for you.

This is especially useful when setting up filters during development.

You immediately get visual guidance, and because only valid operators are available for the selected field type, invalid operator combinations can be avoided.

The generated filter text is then written back to the dataset Filter property.

TTMSFNCFilterDialog

While TTMSFNCDataSetFilterDialog focuses on datasets, TTMSFNCFilterDialog is the more general version.

It uses the same FilterBuilder structure internally, but it is not tied to a TDataSet.

This makes it usable in situations where the data comes from another control or another source.

For example, when using a TTMSFNCDataGrid, the dialog needs to know which columns are available and what data type they represent.

This can be configured directly through the dialog properties or by preparing the FilterBuilder first.

FilterDialog.FilterBuilder.DataColumns.Clear; FilterDialog.FilterBuilder.DataColumns.AddColumn('Age', fdtNumber); FilterDialog.FilterBuilder.DataColumns.AddColumn('Country', fdtText); FilterDialog.FilterBuilder.DataColumns.AddColumn('Active', fdtBoolean);

By defining these columns up front, the dialog can again show the correct fields and only the matching operators.

Events can still be used when you want to fill the available columns dynamically, but for many cases configuring the columns directly is the most straightforward approach.

Using the Dialog with TTMSFNCDataGrid

The TTMSFNCDataGrid now also supports the filter dialog directly.

This means that the grid can offer a visual advanced filtering experience without requiring the user to write the filter text manually.

The dialog uses the grid columns to build the available filter fields and then applies the resulting filter to the grid.

This is useful when the filter becomes more complex than a simple column filter.

For example, when you want to combine multiple conditions:

(Age > 18 AND Country = 'BE') OR (Active = True)

The user can build this visually, while the grid receives a valid filter structure.

Why This Matters

Using a visual filter dialog gives a few practical advantages:

• Users don't need to know the actual field names.
• Only operators that match the selected field type are shown.
• AND/OR mismatch errors are prevented while building the filter.
• Values can be entered with guidance based on the field type.
• Existing filters can be opened and edited visually.
• Nested filter groups with AND and OR become easier to create.
• The generated filter text can still be used with the existing filtering mechanism.

The important part is that the dialog doesn't introduce a separate filtering system.

It builds on the same structured filter logic from the FilterBuilder and helps users create that structure visually.

Next Step

With the FilterDialog, users can create filters in a guided way through a dialog.

In the next blog post, we'll take this one step further with TTMSFNCFilterView.

Instead of opening a dialog, users will interact directly with controls such as checkboxes, combo boxes, sliders and date pickers, while the filter is updated automatically in the background.

The July 2026 update of TMS BIZ is out, and it's a big one for anyone building authenticated, data-driven Delphi backends. The headline is identity brokering in TMS Sphinx — "Login with Google / Microsoft" for your own apps — but there's a lot more under the hood: pluggable password hashing, external-only login pages, chunked streaming in XData, cleaner REST URLs, X.509-based JWT verification in the core library, and a batch of stability fixes across Sparkle and Aurelius.

Here's a tour of what's new, roughly in order of how much it's likely to change the way you build apps.

1. Login with Google, Microsoft and more — identity brokering in TMS Sphinx

TMS Sphinx is an OAuth 2.0 and OpenID Connect authentication and authorization server framework for Delphi. With this release, Sphinx can act as an identity broker: it delegates authentication to an upstream provider like Google or Microsoft Entra, receives the result, maps it to a local user, and still issues its own tokens and manages its own sessions.

In practice, that means you can now add a row of familiar "Continue with Google" / "Sign in with Microsoft" buttons to your login page — or transparently route a corporate customer to their identity provider — with almost no plumbing on your side. PKCE, state, nonce, token validation and user reconciliation are all handled for you.

This feature is large enough to deserve its own article, which walks through registering a provider, adding the buttons, automatic user provisioning, multi-tenant Entra and more:

👉 Login with Google, Microsoft and More — Identity Brokering in TMS Sphinx

The rest of this post covers everything else in the release.

2. Bring your own password hashing (TMS Sphinx)

Sphinx has always hashed and salted stored passwords for you. But security requirements differ: your organization may mandate a specific algorithm (bcrypt, argon2, a particular PBKDF2 configuration), or you may be migrating users from a legacy system whose hashes you need to keep verifying.

You can now replace Sphinx's password hashing entirely. Implement the new IPasswordHasher interface and assign it to TSphinxConfig.PasswordHasher. Every hash and verify operation Sphinx performs goes through your implementation:

uses
  Sphinx.PasswordHasher, Sphinx.Entities;

type
  TBcryptPasswordHasher = class(TInterfacedObject, IPasswordHasher)
  public
    function HashPassword(User: TUser; const Password: string): string;
    function VerifyHashedPassword(User: TUser; const HashedPassword,
      ProvidedPassword: string): Boolean;
  end;

function TBcryptPasswordHasher.HashPassword(User: TUser;
  const Password: string): string;
begin
  // Delegate to your bcrypt/argon2/PBKDF2 routine of choice.
  // The returned value should carry algorithm id, parameters and salt.
  Result := MyBcrypt.HashPassword(Password);
end;

function TBcryptPasswordHasher.VerifyHashedPassword(User: TUser;
  const HashedPassword, ProvidedPassword: string): Boolean;
begin
  Result := MyBcrypt.Verify(ProvidedPassword, HashedPassword);
end;

Wire it up once at startup:

  SphinxConfig1.PasswordHasher := TBcryptPasswordHasher.Create;

When no custom hasher is assigned, Sphinx keeps using its built-in default. A couple of things to keep in mind: the returned hash should embed everything VerifyHashedPassword needs to validate it later, and the implementation is shared across concurrent requests — so make it stateless and thread-safe.

3. External-only login and a smoother sign-out (TMS Sphinx)

Two more Sphinx additions round out the authentication experience.

Hide the password form entirely. If you want users to sign in only through external providers, set:

  SphinxConfig1.LoginOptions.AllowPasswordLogin := False;

The login page then shows just the provider buttons — no username/password fields. (There's a safeguard: if no external providers happen to be available, the local form is still shown so you can't accidentally lock everyone out.)

Redirect back after single sign-out. TSphinxLogin.LogoutAndEndSession and its web counterpart TSphinxWebLogin.LogoutAndEndSession now accept an optional post-logout redirect URI, so the browser can return to a page of your choosing once the SSO session ends:

  SphinxWebLogin1.LogoutAndEndSession('https://myapp.com/goodbye');

For TMS Web Core apps, the new TSphinxWebLogin.ManualCallbackCheck property lets you suppress the automatic OAuth callback check that runs when the component loads, giving you explicit control over when the login flow starts. This release also fixes a Base64 URL-safe decoding issue that affected JWT payloads containing non-ASCII characters in Web Core, and resolves an access violation when AuthResult was read before login.

4. Streaming responses of unknown size (TMS XData)

TMS XData is a framework for building REST APIs in Delphi, built on top of Aurelius and Sparkle. A common pattern is a service operation that returns a TStream — a generated report, an export, a proxied download.

Until now, that stream needed a known size so XData could set Content-Length. This release adds support for streams of unknown size — those whose Size returns a negative value, such as non-seekable pipes or live-generated content. In that case XData automatically switches to chunked transfer encoding instead of a fixed Content-Length:

function TReportService.Export: TStream;
begin
  // A non-seekable stream whose final size isn't known up front.
  // XData sends it with chunked transfer encoding automatically.
  Result := TMyLiveExportStream.Create;
end;

Just as importantly, the stream is now copied to the client in buffered blocks rather than loaded into memory all at once — so large downloads no longer spike your server's memory usage.

5. Cleaner REST URLs with key-as-segment (TMS XData)

By OData convention, XData addresses a single entity with a parenthesized key: /Customer(1). Many REST clients and API gateways prefer the more conventional path-segment style /Customer/1.

The XData client can now speak that dialect. Set the new EntityKeyAsSegment property and the client builds segment-style URLs:

  Client := TXDataClient.Create;
  Client.Uri := 'https://server/tms/xdata';
  Client.EntityKeyAsSegment := True;

  // Requests /Customer/1 instead of /Customer(1)
  Customer := Client.Get<TCustomer>(1);

6. X.509 certificate-based JWT verification (TMS BIZ Core Library)

The TMS BIZ Core Library (BCL) is the foundation the other libraries build on, including the JOSE/JWT implementation used across Sphinx and XData. This release syncs it with the latest upstream Delphi JOSE JWT library and adds several useful capabilities.

The most notable: verifying JWT signatures against an X.509 certificate. If a token issuer publishes its signing key as a PEM-encoded certificate (rather than a raw JWK), you can now extract the public key straight from that certificate:

uses
  Bcl.Jose.Core.JWS, Bcl.Jose.Core.Base;

var
  JWS: TJWS;
begin
  JWS := TJWS.Create(nil);
  try
    JWS.SetKeyFromCert(CertificatePem);   // PEM-encoded X.509 certificate
    JWS.CompactToken := TheJwtToken;
    if JWS.VerifySignature then
      // signature is valid
  finally
    JWS.Free;
  end;
end;

Alongside that, this version brings stricter, safer token handling and a few new helpers:

• TJWS.CheckCompactToken now validates that each decoded token part is valid UTF-8 and well-formed JSON before accepting the token.
• New TJOSEBytes.IsValidString and TJSONUtils.IsValidJSON methods let you validate token parts before deserialization.
• TJWTClaims.ClaimExists is now public, so you can check whether a claim is present.
• TJSONUtils.SetJSONRttiValue now handles dynamic-array claim values, and new IsJSONBool / GetJSONBool helpers read JSON booleans correctly.
• JWT validation error messages are more descriptive, making token failures easier to diagnose.
• A Pointer/Integer cast that misbehaved on 64-bit platforms has been corrected.

7. Aurelius: documented dataset and a cached-updates fix

TMS Aurelius is an ORM framework for Delphi. Two improvements land this cycle.

First, TAureliusDataset — the TDataset descendant that binds Aurelius objects to Delphi's data-aware controls — now has full reference documentation for the class, its associated types, and all public properties and methods, plus an improved guide chapter. If you build VCL/FMX UIs directly over your entities, this fills in a lot of previously undocumented surface area.

Second, a correctness fix in cached updates: when calling TObjectManager.ApplyUpdates with cached updates enabled, extra actions generated during the flush (for example, persisting a new object inside an OnInserted handler) were cached but never executed — silently discarded at the end of the call. Those actions are now applied correctly.

8. Sparkle: stability under real-world conditions

TMS Sparkle is the high-performance HTTP server framework underpinning XData, RemoteDB and Sphinx. Two robustness fixes ship here:

• The Indy-based server no longer crashes when a client disconnects before the response is sent, in setups using an IOHandler such as TaurusTLS under Linux.
• Re-entrant requests dispatched synchronously on the same thread — for example, an in-process engine serving a nested request issued from within a handler — no longer lose the outer request's context. Sparkle now saves and restores the previous context instead of clearing it unconditionally.

Getting the update

All of these libraries ship together as part of TMS BIZ. Existing customers can update through their usual channel; if you're evaluating, grab the trial from the TMS Software website.

The quickest way to get the update is with Smart Setup — the free package manager for TMS products. It resolves dependencies, downloads and builds everything for you, so you can move from this announcement to the new bits with a single command:

tms update tms.biz.*

Prefer a UI? The Smart Setup GUI does the same with a single click.

For the full details, see the per-product release notes:

• TMS Sphinx release notes
• TMS XData what's new
• TMS Aurelius what's new
• TMS BCL release notes

And don't miss the deep dive on the release's marquee feature: Login with Google, Microsoft and More — Identity Brokering in TMS Sphinx.

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.