Your REST API is finished. The endpoints work, the queries are fast, it runs beautifully when you press F9. Now put it in production.

That's usually where a Delphi server project gets complicated. The application that was so pleasant to debug has to become a Windows service that starts at boot and runs with nobody logged in. So you add a second project with a TService, and now you maintain two versions of the same server - one you can debug and one you can ship. Somewhere in there appears a {$IFDEF DEBUG} that nobody wants to touch. And if the customer wants it on Linux, that's a third project.

None of that is your business logic. It's hosting: plumbing that has nothing to do with what your server actually does, but that stands between you and a deployed application.

The next version of TMS Sparkle removes it. It adds a hosting layer so that a server is one single project, one executable, that runs unchanged as a console application while you develop, as a Windows service in production, and as a Linux daemon. Three new IDE wizards create servers in this shape for Sparkle, XData and RemoteDB, so you start from it instead of building up to it.

A quick refresher

TMS Sparkle is a high-performance HTTP server framework for Delphi. It's the foundation under TMS XData, a framework for building REST APIs, TMS RemoteDB, a framework for remote database access over HTTP, TMS Sphinx, a full OAuth/OpenID Connect implementation to secure your APIs, among other products. Whatever you build with these products is, at the bottom, a Sparkle server, so everything in this article applies to all those.

One project, three run modes

The new unit Sparkle.Host turns a console program into a server host. The same binary runs:

• as an interactive console application, on Windows and Linux - what you get when you press F9;
• as a Windows service, registered with the Service Control Manager by the executable itself;
• as a systemd daemon on Linux, with a unit file the executable prints for you.

The mode is chosen at runtime, by the command line. Not at compile time: no conditional defines, no separate service project, no TService descendant, no VCL form with Start and Stop buttons. One .dproj to build, debug, version and deploy.

What you deploy is exactly what you debugged. The host takes care of everything that differs between the three modes - the Service Control Manager handshake, POSIX signals, graceful shutdown, exit codes - and your server code never learns which mode it is in.

Start with a wizard

Choose File > New > Other in the IDE, and under Delphi Projects open the TMS BIZ category. All TMS BIZ wizards are now grouped there, including three that create a ready-to-run hosted server: TMS Sparkle Server, TMS XData Server and TMS RemoteDB Server.

Pick one and you get a console project targeting Win32, Win64 and Linux64, made of two files. The program file is one line of code:

program XDataConsole;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  Sparkle.Host,
  ServerModuleUnit in 'ServerModuleUnit.pas' {ServerModule: TDataModule};

begin
  RunHost(TServerModule);
end.

The second file is a data module with the server components already dropped and wired, ready for you to configure. That data module is your application: RunHost creates it when the host starts and frees it when the host stops, so you write your endpoints and your logic there and ignore everything else.

Press F9. A console window opens:

2026-09-11 10:15:02 [info] Now listening on: http://localhost:2001/tms/xdata

Open the address in a browser, press Ctrl+C to stop it. Requests in progress finish, the server shuts down cleanly, and you're back in the IDE. That's the whole development loop, and it is identical on Windows and on Linux.

The generated server uses the Sparkle socket server, which behaves the same on both platforms and needs no administrative setup. If you'd rather run on Http.sys for a high-load Windows server, the generated code has the lines for it ready to uncomment.

Deploy on Windows: one command

There's no service project to build. The executable you have just been debugging installs itself. From an elevated command prompt:

MyServer.exe --install

That's it. Your server is now a Windows service, set to start automatically at boot, and you manage it like any other:

sc start MyServer
sc stop MyServer

MyServer.exe --uninstall removes it. When it runs as a service there is no console to write to, so the host writes the log lines to a file next to the executable (or wherever you point it with --log=).

Run the executable with --help and it lists everything it accepts. No hand-written service registration, no sc create command line to get right, no separate installer step.

Deploy on Linux: one pipe

The same program writes its own systemd unit file:

./myserver --systemd-unit | sudo tee /etc/systemd/system/myserver.service
sudo useradd -r myserver
sudo systemctl daemon-reload
sudo systemctl enable --now myserver

Four lines, and your server starts at boot, runs under its own user account and restarts if it fails. Nothing else is installed on the machine: no Apache, no web server in front, just your binary. systemctl stop sends SIGTERM, which becomes the same graceful shutdown as Ctrl+C, and the log goes to the journal:

journalctl -u myserver -f

Everything in one process

A backend is rarely only HTTP. There's a nightly import, a queue to poll, a scheduler - things that used to justify yet another project and another service to install and monitor. The host runs them alongside your servers, in the same process, with the same lifetime:

begin
  CreateHost
    .ServiceOptions('SalesApi', 'Sales API Server', 'REST API for the sales system')
    .Add(TApiServerModule)
    .Add(TReportsServerModule)
    .Add(TNightlyJobsWorker)
    .Run;
end.

CreateHost takes any number of data modules and background workers, starts them in order and stops them in reverse. ServiceOptions is the name, display name and description the service gets when you install it. And if something fails to start - a port already taken, a database that isn't there - whatever is running is stopped, the error is logged, and the process exits with code 1, so the failure is visible to systemd, to the Service Control Manager and to your deployment script instead of looking like a normal shutdown.

A worker is that job runner or scheduler: a class with a loop of its own. Derive from THostedWorker, override Execute, and the host gives it a thread:

type
  TNightlyJobsWorker = class(THostedWorker)
  protected
    procedure Execute(const AStop: IStopToken); override;
  end;

procedure TNightlyJobsWorker.Execute(const AStop: IStopToken);
begin
  repeat
    RunPendingJobs(AStop);
  until AStop.WaitFor(60000);
end;

The loop waits on the IStopToken instead of calling Sleep, and that's what makes stopping instant: a service stop, a systemctl stop or a Ctrl+C ends the wait immediately, wherever in the minute it happened to be. Pass the token into long-running work and it can give up halfway instead of holding up the shutdown.

Still one project, still one executable.

Already have a server? It's a small change

Existing projects keep working: the previous wizards are still in the gallery under TMS BIZ (Deprecated), and the Sparkle.App units still compile.

But moving to the host is usually a few lines. A server generated by the old wizards, for instance, has a Server unit with StartServer and StopServer procedures shared by its VCL, service and console projects. Keep that unit exactly as it is, give it a one-file console project, and the other projects are no longer needed:

uses
  Sparkle.Host,
  Sparkle.Host.Shutdown,
  Server in 'Server.pas';

begin
  RunHost(
    procedure
    begin
      StartServer;
      try
        WaitForShutdown;
      finally
        StopServer;
      end;
    end);
end.

Your server code doesn't change. WaitForShutdown simply replaces the ReadLn you had in the console version - and that single line is what tells the host the server is up, which is what a Windows service has to report to the Service Control Manager and what systemd wants to know.

The migration guide covers this and the other starting points, including hand-written TService projects.

Conclusion

Deployment is the part of a server project that has the least to do with your application and causes the most trouble. The new hosting layer takes it off your hands:

• One project and one executable for development, Windows services and Linux daemons.
• F9 to run, Ctrl+C to stop, with the same code and the same behavior you ship.
• Deployment built into the binary: --install on Windows, --systemd-unit on Linux.
• Correct service behavior for free - graceful shutdown, start and stop reporting, meaningful exit codes.
• Wizards for Sparkle, XData and RemoteDB that create this shape of project for you.
• Existing servers keep working, and move over with almost no code change.

A complete example - an HTTP server and a background worker in one process - ships in the Sparkle distribution under demos/host.

To learn more, read the Hosting chapter in the Sparkle documentation, the getting-started guides for the XData Server wizard and the RemoteDB Server wizard, and the what's new list. And visit the product pages of TMS Sparkle, TMS XData and TMS RemoteDB, all part of TMS BIZ.

TMS Cryptography Pack proposes functions/procedures to generate and decode many PKIX structures using the "PEM" format. That includes certificates, keys and signatures files. It also supported the decoding of PFX certificates (with either keyBag,certBag, or pkcs8ShroudedKeyBag) and as of 5.3.0.0, it supports the generation of PFX for "cert bags" and "key bags".

This post explains how the internal of this feature works.

Why PKCS#12 is trickier than it looks

A .pfx/.p12 file looks like a single opaque blob, but it's a small tower of nested ASN.1 structures, each with its own encoding rules, several of which are easy to get subtly wrong without any error message at write time — the file parses fine, opens in some tools, and then fails silently in others (wrong MAC, unreadable key, orphaned certificate). TX509Certificate implements this format from scratch in Delphi, building and parsing the DER by hand rather than relying on an external ASN.1 library. This article walks through what the format actually requires, how the class implements each layer, and how to cross-check the output against OpenSSL at every step.

The structure, top to bottom

PFX ::= SEQUENCE {
    version     INTEGER {v3(3)},
    authSafe    ContentInfo,
    macData     MacData OPTIONAL
}

authSafe is a ContentInfo of type id-data, whose payload is itself an AuthenticatedSafe ::= SEQUENCE OF ContentInfo. Each element of that sequence carries one "safe" — a certificate, a key, or a group of either — wrapped either in plain id-data or in encryptedData when confidentiality is wanted for that particular safe. Inside each safe sits a SafeContents ::= SEQUENCE OF SafeBag, and each SafeBag carries a typed payload (keyBag,certBag, pkcs8ShroudedKeyBag, CRLBag, SecretBag, and SafeContents) plus an optional set of attributes (localKeyID, friendlyName) used to associate a certificate with its private key.

That's four or five levels of nesting before you reach a single useful byte, and every level has its own tag, its own length, and its own rules about implicit versus explicit tagging. Get one length wrong, or wrap something in [0] IMPLICIT where [0] EXPLICIT was required, and the file becomes silently unreadable to strict parsers while looking fine in lenient ones — a genuinely common failure mode when building this by hand.

New building blocks in TX509Certificate

BuildPKCS8PrivateKeyInfo

Wraps the raw key material (RSA or EC) into a standard PKCS#8 PrivateKeyInfo:

PrivateKeyInfo ::= SEQUENCE {
    version                   INTEGER (0),
    privateKeyAlgorithm       AlgorithmIdentifier,
    privateKey                OCTET STRING
}

For RSA, privateKeyAlgorithm carries rsaEncryption (1.2.840.113549.1.1.1) with NULL parameters. For EC, it carries id-ecPublicKey (1.2.840.10045.2.1) with the named curve's OID as parameters instead of NULL — a detail that's easy to copy-paste wrong from the RSA branch, since both look identical except for that one field.

OpenSSL equivalent — inspecting an unencrypted PKCS#8 key:

openssl pkey -in key.pem -text -noout

BuildPkcs8ShroudedKeyBag

Encrypts the PrivateKeyInfo with PBES2 (RFC 8018): PBKDF2-HMAC-SHA256 to derive the key, AES-256-CBC to encrypt it. The resulting AlgorithmIdentifier looks like:

PBES2 { PBKDF2 { salt, iterations, keyLength, prf }, AES-256-CBC { iv } }

keyLength here is in bytes, not bits.

OpenSSL equivalent — creating a PBES2/AES-256/PBKDF2-SHA256 encrypted PKCS#8 key directly:

openssl pkcs8 -topk8 -v2 aes-256-cbc -v2prf hmacWithSHA256  -in key.pem -out key_encrypted.pem

BuildCertBag

For a certificate stored unencrypted, the SafeBag points directly at type x509Certificate (1.2.840.113549.1.9.22.1):

SafeBag { bagId=x509Certificate, bagValue=[0]{OCTET STRING cert}, bagAttributes }

BuildBagForEncryption + BuildEncryptedContentInfo

For a certificate stored encrypted, OpenSSL — and this class, once corrected to match it — uses a different, doubly-nested bagId:

SafeBag {
  bagId = certBag (1.2.840.113549.1.12.10.1.3),
  bagValue = [0] EXPLICIT SEQUENCE {
      certType  = x509Certificate,
      certValue = [0] EXPLICIT OCTET STRING (the cert DER)
  },
  bagAttributes
}

This whole SafeBag — not just the certificate — is what gets encrypted, as the plaintext of an EncryptedContentInfo sitting inside a ContentInfo of type encryptedData (1.2.840.113549.1.7.6) at the AuthenticatedSafe level:

ContentInfo {
  contentType = encryptedData,
  content = [0] EXPLICIT EncryptedData {
      version = 0,
      encryptedContentInfo = SEQUENCE {
          contentType = id-data,
          contentEncryptionAlgorithm = PBES2 { ... same shape as the key ... },
          encryptedContent = [0] IMPLICIT OCTET STRING
      }
  }
}

Two details worth calling out because they don't announce themselves as bugs — decryption just silently produces garbage:

• encryptedContent must be tagged [0] IMPLICIT (0x80, a primitive context tag directly in front of the ciphertext bytes), not [0] EXPLICIT (0xA0) wrapping an inner OCTET STRING. Both parse as valid DER, so a parser can misread one for the other without erroring — the mismatch only surfaces if you try to decrypt and compare byte-for-byte against a reference.
• The bagValue of the certBag-wrapping SafeBag, and the inner certValue, both need their own [0] EXPLICIT wrapper — easy to drop one level when hand-assembling nested strings.

OpenSSL equivalent — producing a PFX with the certificate encrypted (in addition to the key), with TMS CP supported algorithms:

openssl pkcs12 -export -in cert.pem -inkey key.pem  -out out.pfx -certpbe AES-256-CBC -keypbe AES-256-CBC  -macalg sha256

(Without -certpbe, recent OpenSSL defaults to leaving the certificate in plain id-data — which is also perfectly valid PKCS#12, and the simpler case this class supports as well.)

BuildMacData

The MacData structure authenticates the entire AuthenticatedSafe:

MacData ::= SEQUENCE {
    mac         DigestInfo { algorithm, digest },
    macSalt     OCTET STRING,
    iterations  INTEGER DEFAULT 1
}

The key used for this HMAC is not derived with PBKDF2. RFC 7292's Annex B defines a separate, older key-derivation function specific to PKCS#12: the password is encoded as a BMPString (UTF-16BE, null-terminated), repeated together with the salt to fill whole hash-block-sized buffers, and the hash function is applied iteratively to an evolving buffer rather than through the standard PBKDF2 construction. Reusing the PBES2/PBKDF2 routine here — an easy mistake, since both derive "a key from a password and a salt" — produces a structurally perfect file with a MAC that never validates.

OpenSSL equivalent — verifying a file's MAC and listing its contents:

openssl pkcs12 -info -in file.pfx -noout -passin pass:yourpassword # pick a strong password :-)

A successful run without a MAC-mismatch error is the fastest real-world confirmation that both the AuthenticatedSafe structure and the HMAC are correct together — cheaper than manual ASN.1 inspection for a quick sanity check, though it won't tell you why something is wrong if it fails. You can still use the https://lapo.it/asn1js/ decoder to visualize and check all ASN.1 structures.

Putting it together revisited: ExportToPFX

PKCS8Key := BuildPKCS8PrivateKeyInfo;
InitPfxParameters(Password);
FPfx.EncryptionKey := ASN1.GenerateKDFKey(FPfx.Password, FPfx.KdfSalt,
                                           FPfx.KdfIterations, FPfx.KdfOutputSize * 8);
FPfx.EncryptedKeyset := ASN1.EncryptPrivateKeyInfo(FPfx.EncryptionKey, FPfx.EncryptionIV, PKCS8Key);

CertBag := BuildCertBag(FCrtRaw);                     // or BuildBagForEncryption, for the encrypted path
KeyBag  := BuildPkcs8ShroudedKeyBag(FPfx.EncryptedKeyset);

SafeContents := BuildSafeContents(CertBag, KeyBag);    // = the AuthenticatedSafe itself
AuthSafe     := BuildContentInfoData(SafeContents);    // outer ContentInfo wrapper
MacData      := BuildMacData(SafeContents);            // MAC over the AuthenticatedSafe, not SafeContents' inner bags

PFX := BuildPfxRoot(AuthSafe, MacData);

The naming here is a little misleading on purpose: SafeContents is where the two per-bag ContentInfo elements are actually assembled, making it the true AuthenticatedSafe; AuthSafe is one further wrapper around that, the outer ContentInfo that becomes PFX.authSafe. Keeping straight which buffer the MAC is computed over — the AuthenticatedSafe, always including its own SEQUENCE tag and length, never the bare concatenation of bags inside it, and never the doubly-wrapped AuthSafe — is the single detail most worth getting right first, since every other structural mistake tends to surface as a parse error, while this one surfaces only as a MAC that mysteriously never matches.

Testing checklist

For anyone extending (not all OIDs are present) or auditing code like this, the fastest feedback loop is:

1. Structural check — openssl asn1parse -inform DER -in file.pfx -i, or -strparse <offset> to descend past an outer OCTET STRING that the tool won't auto-recurse into.
2. Integrity check — openssl pkcs12 -info -in file.pfx -noout -passin pass:...; a MAC failure here means the buffer hashed at export didn't match the buffer written.
3. Round-trip check — decrypt and re-import with a second, independent implementation (even a short Python script using cryptography and hashlib.pbkdf2_hmac) rather than trusting your own decoder, since a decoder written by the same hand as the encoder will happily agree with its own mistakes.

More OpenSSL examples are provided in the \Demo\VCL\PFX folder. Several PFX certificates to test the decode function can be found in the \Demo\VCL\PFX\Certs folder. 

The VCL Demo has been updated to generate standard X509 certificates and PFX certificates, for which a password is required.

Customer Case

Hawk One: a voxel helicopter game written in Delphi with TMS WEB Core

In the 1990s, Ralf Kählke spent a lot of time playing Comanche, NovaLogic's helicopter game with its voxel landscapes. What stuck with him was flying low over the mountains and valleys, using hills as cover. Somewhere along the way he added an item to his personal to-do list: build a helicopter game like that himself.

More than thirty years later, he did. Hawk One is now playable on itch.io, it runs in the browser, and it is written in Delphi and compiled to JavaScript with TMS WEB Core.

Play Hawk One

It started with a renderer

Hawk One wasn't a game at first. Ralf wanted to find out whether he could write his own voxel-style terrain renderer and get it fast enough to run in a web browser. There is no Unity or Unreal underneath. The renderer, flight model, HUD and game logic are his own Pascal code.

The first versions ran at 9 frames per second. A lot of the work after that went into keeping calculations out of the render loop and precomputing terrain data, until the frame rate was acceptable on a desktop PC and later on phones and tablets too.

Once he could fly over his own landscape, the project grew into a game almost by itself. Helicopter movement came first, then a HUD, a minimap, radar contacts and a compass. After that came weapons: a gun plus air-to-ground and air-to-air missiles, with target locking, ammunition and scoring.

The current mission gives you five minutes to find and destroy every enemy radar contact. A radio officer briefs you before takeoff and has something different to say afterwards depending on how it went.

Keyboard, gamepad and touch

Input turned out to be harder than Ralf expected. Controls that feel right on a keyboard don't work on a controller, and neither works on a phone. Hawk One now switches between them automatically. On a desktop you can use the keyboard or plug in a gamepad, which also works in the menus. On a phone or tablet, two virtual joysticks and touch buttons appear on screen. There are two flight models as well. Arcade is the default, so you can start flying without reading a manual, and a more simulation-oriented option is there for people who want it.

The game can also be installed as a Progressive Web App and launched from the home screen, so the same build runs on a Windows PC, a tablet and a phone.

Why we like this project

Most TMS WEB Core applications we see are business software: dashboards, forms, portals, back-office tools. Hawk One is a different kind of workload. A real-time renderer redraws the whole screen every frame and has to react to input with no noticeable lag, and here all of that code is written in Object Pascal.

Ralf's day job is on the business side. He runs his own company, SQLmanagement Kählke, and for nearly 30 years he has been developing and licensing HK/2, a software package for sub-metering and heating cost billing. HK/2 is built with a range of TMS components, including TMS WEB Core and TMS XData. Hawk One is a side project, written with the same language and much of the same tooling he uses for his commercial software. It shows that TMS WEB Core can handle performance-sensitive code in the browser, and that Delphi developers can bring their existing skills to a platform that runs on nearly any device.

It's also a lot of fun to play.

An early version, and he wants feedback

Hawk One is in active development. Ralf plans more missions, enemies that fight back, more varied terrain, better effects and more sound. He's asking players how the controls feel, how the game performs on their device, and whether the five-minute mission is too easy or too hard. If you try it, leave a comment on the itch.io page.

Have you built something unusual with TMS WEB Core? We'd like to hear about it.

What's included

• TMS AI Studio
• TMS VCL UI Pack
• TMS FNC UI Pack
• TMS WEB Core
• TMS FlexCel for VCL & FMX
• TMS Aurelius
• TMS Analytics & Physics Pack
• TMS Async
• TMS MQTT

Why this is worth trying this semester

How to get started

1. Go to the TMS Academic page
2. Register with your academic email address
3. Log in and download the installer for the product (or products) you need
4. Download TMS Smart Setup, our command-line and GUI installer, and log in with the credentials you received
5. Install the product (or products)

AI is moving at a pace that's hard to keep up with — new models every few months, new providers, new ways for an assistant to actually do something instead of just answering questions. Delphi developers shouldn't have to sit on the sidelines of that while everyone else builds in Python or JavaScript. That's the whole premise of TMS AI Studio: bring modern AI — cloud models, local models, and the tool-calling standard that ties them to real applications — into native Delphi, with one consistent way of working across all of it.

Version 2.0 pushes on every one of those fronts at once. It keeps pace with the fastest-moving part of the AI world — MCP, the Model Context Protocol that lets assistants like Claude and ChatGPT call into your own tools — while adding a major new AI provider, OpenRouter.ai, to the growing list you can already reach from a single component. And crucially, none of it costs you a rewrite: everything you built on an earlier version keeps working exactly as it did.

Always on the newest revision of MCP

The real headline here is the newest revision on the block: 2026-07-28, published only weeks ago, is already fully supported — not on a roadmap, not "coming soon," but there today, on both the server and client side. And it doesn't stand alone: everything the spec has added since the very first release in late 2024 — five revisions in total — is supported right alongside it, so nothing an older assistant relies on stops working the moment a newer one shows up.

That's what staying current with MCP actually means in practice: not scrambling to catch up every time the spec moves, but already being there when it does.

Under two years old, five revisions in, and TMS AI Studio hasn't missed one.

Upgrade today. Nothing breaks.

None of the above is something you opt into feature by feature. Recompile an existing MCP server or client against v2.0, and it's simply fluent in more of the protocol than it was before — because the server and whatever connects to it always agree, automatically, on the newest dialect they both happen to know. An older assistant still gets a correct conversation; a newer one gets everything the latest revision has to offer. Your code doesn't need to know the difference:

// exactly the code you already have
Server := TTMSMCPServer.Create(Self);
Server.Transport := Transport;
Server.RegisterTool('get_weather', GetWeatherHandler);

// on v2.0, this same server now negotiates
// protocol revision 2026-07-28 with any client that supports it —
// nothing above this comment changed to make that happen

The same is true if you're building the other end of that connection. A TTMSMCPClient you already wrote does exactly the same negotiation, automatically, the moment it connects:

// exactly the code you already have, on the client side
var
  Server: TTMSMCPClientServerItem;
begin
  Client := TTMSMCPClient.Create(Self);
  Server := Client.Servers.Add;
  Server.TransportType := ttHTTP;
  Server.URL := 'https://your-mcp-server.com/mcp';
  Server.Start;
end;

// on v2.0, this same client also negotiates the newest
// protocol revision the server understands — again, nothing
// above this comment needed to change

Forward on both sides of the conversation

It's easy for a release like this to quietly favor one side — the server catches up, the client lags behind. Not here. Both directions move forward together, and a couple of smaller conveniences arrive with them: connected assistants now find out immediately when you add or remove a tool, resource, or prompt — no extra call required —

Server.Tools.RegisterTool('add_note', AddNoteHandler);
// that's it — every connected assistant is told about
// the new tool automatically, the moment it's registered

— and sign-in now works the same way in both directions, as the next section covers.

OAuth in the client: signing in without writing a sign-in flow

A server-side login screen is only half of OAuth. The other half is a client that knows how to react when a server says "not so fast" — and until now, that side of the conversation was something you had to build yourself. In v2.0, TTMSMCPClient does it for you.

When a protected MCP server answers with "unauthorized," the client's transport notices on its own, works out which login service to trust, opens the system browser for the user to sign in and approve access, and — once that's done — retries the original request with the token it just received. No callback to wire up, no token storage to write, no retry logic of your own:

var
  Server: TTMSMCPClientServerItem;
begin
  Client := TTMSMCPClient.Create(Self);
  Server := Client.Servers.Add;
  Server.TransportType := ttHTTP;
  Server.URL := 'https://your-mcp-server.com/mcp';
  Server.Start;
end;

// if the server responds "unauthorized", the client opens a
// browser, waits for the user to approve, and quietly retries —
// nothing above this line needed to know a login was coming

Three steps, zero lines of sign-in code — the client handles all of it on its own.

Want a hand on the wheel anyway? A handful of events let you step in exactly where it helps — open the sign-in page in your own embedded browser control instead of the system one, choose which login service to use when a server offers more than one, or simply get notified the moment a token comes back. Leave them alone, and the client still signs in correctly without you touching any of it.

One gateway, hundreds of AI models: OpenRouter.ai support

With the latest extension to TMS AI Studio, Delphi developers can now also use OpenRouter.ai as a cloud LLM service. Switching to OpenRouter is as simple as changing a single property:

TMSMCPCloudAI1.Service := aiOpenRouter;

From that point on, TMS AI Studio takes care of the service integration, allowing your Delphi application to access the wide range of AI models available through OpenRouter's unified API.

The model to use can be selected through:

TMSMCPCloudAI1.Settings.OpenRouterModel := 'z-ai/glm-5.3-flash';

The default model is z-ai/glm-5.3-flash, which offers an attractive combination of high performance and low usage cost. In fact, attractive pricing is one of the interesting aspects of using OpenRouter.ai. It provides access to a very broad selection of models, with many capable models available at remarkably low token prices. This makes OpenRouter particularly interesting for developers who want to experiment with different LLMs, as well as for applications where AI is used frequently and inference cost therefore becomes an important consideration.

Of course, another major strength of OpenRouter.ai is that you are not tied to a single model provider. Its catalog provides access to a large and continuously evolving selection of models, including popular model families from OpenAI, Anthropic Claude, Google Gemini, Meta Llama, DeepSeek, Qwen, Mistral, xAI Grok, Z.AI GLM, and many others. This makes it particularly convenient to experiment with different models or select the best model for a particular task without having to implement a different API integration for every AI provider.

Another interesting OpenRouter feature, especially for professional and European users, is its support for data residency and provider routing controls. With the appropriate OpenRouter business offering, routing can be restricted to infrastructure in specific regions, such as EU-only or US-only processing. This can be important when considering data privacy, regulatory requirements and data sovereignty policies.

And this is precisely where TMS AI Studio becomes especially powerful. OpenRouter.ai is yet another service that plugs into the same Delphi-friendly architecture:

Ten AI providers, cloud and local, behind one consistent component. OpenRouter is simply the newest door into that same room.

With the meanwhile extensive range of directly supported cloud LLM services, local LLMs and hundreds of available models, developers can integrate AI into Delphi applications through one consistent component API. Changing from a local model to a cloud model—or experimenting with an entirely different model family—can often be reduced to changing just a service or model property, while the rest of the application code remains unchanged.

With OpenRouter.ai added to TMS AI Studio, Delphi developers gain even more choice in models, providers, performance and pricing, while continuing to work with the same familiar TMS AI Studio component architecture.

More models, more providers, attractive AI pricing and more deployment choices—without adding more complexity to your Delphi application.

Easier to learn, easier to build on

Alongside the release itself, a few things changed in how you actually get to it. Full documentation for everything in v2.0 is already up, covering the protocol negotiation, the client-side OAuth flow, and every CloudAI provider in detail. TMS AI Studio also joins the new install experience introduced across TMS products, and as part of that, the demos move to their own GitHub repository — so you can freely edit them, keep your changes under version control, and not have to worry about a future install or Smart Setup run quietly overwriting the copy you've been working in.

What v2.0 adds up to

AI is changing fast, on every front — new models, new providers, new standards for how assistants reach real applications. TMS AI Studio v2.0 is about making sure Delphi doesn't have to wait to benefit from any of it. Your existing MCP servers and clients keep working, unchanged, while gaining everything the newest protocol revision has to offer, on both ends of the connection. Signing in to a protected server is no longer something you build by hand on either side. And reaching a wider, cheaper, ever-growing spread of AI models is now a one-line change rather than a new integration.

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

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

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

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

For this, we've added:

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

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

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

Starting from our Report Generator

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

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

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

Adding Filtering: One Line

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

Grid.Options.Filtering.Enabled := True;

That's it.

With one property, the DataGrid gets its filtering interface.

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

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

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

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

Need More? Enable Advanced Filtering

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

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

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

Grid.Options.Filtering.Advanced := True;

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

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

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

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

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

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

No separate filtering system needs to be developed.

Conditional Formatting: A Brand-New DataGrid Feature

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

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

our dedicated conditional formatting blog post .

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

Enabling conditional formatting requires:

Grid.ConditionalFormatting.Enabled := True;

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

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

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

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

Let the User Create the Rules

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

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

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

Grid.Root.ShowConditionalFormattingEditor;

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

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

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

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

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

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

Configure Once, Use Again

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

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

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

Grid.ConditionalFormatting.SaveToJSONStream(Stream);

The resulting JSON can later be loaded again with:

Grid.ConditionalFormatting.LoadFromJSONStream(Stream);

The sample stores the conditional formatting configuration in:

FNCDBReporterFormatting.json

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

Grid.Filter.FilterText

The sample stores this expression separately in:

FNCDBReporterFilter.ini

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

Grid.FilterBuilder.FilterText := FilterText;

and applied:

Grid.RemoveFilter; Grid.ApplyFilter;

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

Save Your Report View

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

We're no longer just saving or exporting data.

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

For example, imagine a sales report where somebody:

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

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

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

A Lot of Functionality, Very Little Code

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

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

With TTMSFNCDataGrid, the core functionality is already available.

The essential calls are remarkably small:

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

This is the real advantage of the approach.

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

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

From Static Report to Interactive Report

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

With these additions, that report becomes much more interactive.

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

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

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

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

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

We also showed the following example:

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

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

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

There is no dataset filter involved.

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

Setting Up the Planner

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

Adding an appointment is nothing special:

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

Some examples used in the demo are:

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

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

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

Creating the Filter Rules Manager

We start by creating a TTMSFNCFilterRulesManager:

FRM := TTMSFNCFilterRulesManager.Create(Self);

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

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

Adding a Dynamic Search Value

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

Our search text comes from a TEdit called SearchEdit.

We register its Text property as a placeholder:

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

From this point on, we can use:

{Search}

inside our rule.

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

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

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

Creating the Rule

Now we can create the actual rule:

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

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

Let's break it down.

1. The Rule Name

'SpotlightRule'

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

2. The Source

TMSFNCPlanner1

This is the object where the Filter Rules Manager starts.

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

That's where the next parameter comes in.

3. The Items Path

'Items'

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

In this example, that means every TTMSFNCPlannerItem inside:

TMSFNCPlanner1.Items

The rule is therefore applied to each appointment individually.

4. The Filter Expression

Finally, we have the actual condition:

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

This is where things become interesting.

Title is not a field from a dataset.

It is the Title property of TTMSFNCPlannerItem.

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

If the user enters:

Team

the effective condition becomes:

[Title] LIKE '%Team%'

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

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

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

What Should Happen When an Item Matches?

We now know whether each appointment matches the search.

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

We could hide appointments that don't match.

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

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

For that, we use CallBackAction:

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

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

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

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

When it matches, we restore its original colors.

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

One Match, Multiple Property Changes

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

One condition can affect multiple properties.

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

• Color
• StrokeColor
• FontColor
• TitleFontColor
• MarkColor

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

[Title] LIKE '%{Search}%'

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

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

Making the Search Live

We have created the rule only once.

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

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

The UpdateFilter method itself remains very small:

procedure TFormFilterRules.UpdateFilter;
begin
  FMatchCount := 0;

  FRM.ApplyRule(FRule1);

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

Notice what isn't happening here.

We aren't:

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

We simply apply the existing rule again.

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

What Happens When the Rule Is Disabled?

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

For that, we can provide an InactiveCallBackAction.

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

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

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

This gives us three clear states:

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

The Complete Rule Setup

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

FRM := TTMSFNCFilterRulesManager.Create(Self);

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

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

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

And when the search changes:

FRM.ApplyRule(FRule1);

That's the core of the example.

Not Just a Planner Feature

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

The important ingredients are:

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

In this example:

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

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

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

Filtering Without Removing Anything

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

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

Here, every appointment remains in the Planner.

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

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

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

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