Exporting a GPX file through the device share sheet

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

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

  UILogic.ExportToGPX(TMSFNCMaps, LFileName);

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

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

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

LIntent.addFlags(
  TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION
);

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

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

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

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

LRootVC.presentViewController(LActivity, True, nil);

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

Converting AI-generated descriptions into speech

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

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

FMP3Player := TStreamMP3Player.Create;

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

Playing an MP3 stream with FireMonkey

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

FMP3Player.Play(SoundBuffer);

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

  ReleaseMedia;

  LFileName := CreateTempMP3FileName;

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

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

Conclusion

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

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

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

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

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

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

TTMSFNCFilterView and TTMSFNCDataGrid

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

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

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

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

In the video, you will see how:

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

Configuring the Filter Controls

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

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

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

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

A CheckBox can represent a Boolean value:

Active = True

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

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

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

Applying the Filter

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

You can:

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

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

Using Your Own Controls

The built-in controls cover many common filtering scenarios.

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

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

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

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

Filter View Control Container

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

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

You configure the expression that the control represents:

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

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

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

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

ControlContainer.FilterExpression.AddToFilter := False;

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

Registering Controls Programmatically

Controls can also be registered directly with the Filter View.

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

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

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

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

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

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

One Filtering Model, Different Interfaces

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

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

All of these approaches create the same structured filtering model.

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

Why Build a Custom Filter Interface?

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

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

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

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

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

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

Less Repetitive Filtering Code

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

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

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

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

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

What's Next?

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

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

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

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

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

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

See it in action

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

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

Everything is open source

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

The full project is available on GitHub:

Built with TMS components

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

The application was built using:

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

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

Simply use coupon code during checkout to activate the discount.

Coming next: Behind the scenes

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

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

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

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

Build it. Customize it. Share it.

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

To run the application you'll need:

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

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

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

Deploying a Delphi HTTP backend on Linux has always involved a decision you didn't really want to make.

You could build an Apache module with WebBroker — which means installing and configuring Apache on every server, matching module ABIs, and debugging a stack where your code is a guest in someone else's process. Or you could use the Indy-based server — self-contained, but with no built-in HTTPS (you need a third-party IOHandler), no WebSockets, and modest throughput.

Meanwhile, on Windows, Sparkle servers have had a first-class, kernel-mode HTTP server for a decade.

That gap is now closed. The next version of TMS Sparkle introduces the socket server: a complete, high-performance HTTP server written entirely in Delphi, on raw sockets. Your Linux deployment becomes a single executable that you copy to the machine and run. No Apache. No nginx. No third-party libraries to install and keep updated.

A quick refresher on TMS Sparkle

TMS Sparkle is a high-performance HTTP server framework for Delphi. It's the foundation under TMS XData (REST APIs), TMS Sphinx (OAuth 2.0 / OpenID Connect) and TMS RemoteDB (remote database access over HTTP).

Sparkle separates what your server does — modules, middleware, request handlers — from how requests reach it. That "how" is the dispatcher, and until now on Linux your dispatcher choices were Apache or Indy. The socket server is a new dispatcher, and because it implements the same module contract as all the others, existing Sparkle, XData and RemoteDB servers run on it unchanged.

Hello, world

The server class is TSocketHttpServer, in unit Sparkle.Socket.Server. If you've ever written a Sparkle server for Windows with THttpSysServer, this will look extremely familiar:

uses
  Sparkle.Socket.Server;

var
  Server: TSocketHttpServer;
begin
  Server := TSocketHttpServer.Create;
  try
    Server.AddModule(TMyServerModule.Create('http://localhost:8080/myapplication'));
    Server.Start;

    WriteLn('Server running. Press ENTER to stop.');
    ReadLn;

    Server.Stop;
  finally
    Server.Free;
  end;
end;

That's a complete HTTP server. Compile it for Linux 64-bit, copy the binary to the machine, run it — done.

Stop performs a graceful shutdown: listeners close, requests in flight are allowed to finish, and active WebSocket sessions are terminated cleanly.

A note on the host name. The socket server uses only the port of each module base URL to decide what to listen on — it always binds all interfaces (IPv4 and IPv6) — and routes requests to modules by path only. The host part is ignored, so localhost, 0.0.0.0 or your real domain name all behave the same. That matches the Http.Sys dispatcher, which by default replaces the host with the + wildcard as well (unless you set KeepHostInUrlPrefixes). In other words, the same base URL works on both dispatchers — and if you need to restrict who can reach the server, that's a job for a firewall rule or a reverse proxy.

The same applies to an XData REST API, which needs no changes at all beyond the dispatcher you host it in:

uses
  XData.Server.Module,
  Sparkle.Socket.Server;

  Server := TSocketHttpServer.Create;
  Server.AddModule(TXDataServerModule.Create(
    'http://localhost:2001/tms/xdata', ConnectionPool));
  Server.Start;

HTTPS that fits how Linux actually works

On Linux, certificates are PEM files on disk, usually renewed automatically by certbot. The socket server works exactly that way — register modules with an https URL and point the Ssl property (TSslOptions) at your files:

  Server := TSocketHttpServer.Create;
  Server.Ssl.CertificateFile := '/etc/letsencrypt/live/myapp.com/fullchain.pem';
  Server.Ssl.PrivateKeyFile := '/etc/letsencrypt/live/myapp.com/privkey.pem';
  Server.AddModule(TMyServerModule.Create('https://myapp.com:443/myapplication'));
  Server.Start;

TLS is provided by OpenSSL 3, loaded dynamically at runtime. On current distributions (Ubuntu 22.04+, Debian 12+, RHEL 9+) OpenSSL 3 is already installed, so there is nothing extra to deploy with your application. TLS 1.2 and TLS 1.3 are both supported.

Two features matter a lot in production:

Several certificates on one port (SNI). Serve multiple host names from one server, with the right certificate picked from the name the client asks for. Add TSslCertificate entries to SniCertificates; wildcards are supported:

var
  Cert: TSslCertificate;
begin
  Cert := TSslCertificate.Create;
  Cert.HostName := '*.example.com';
  Cert.CertificateFile := '/etc/myserver/example-com.pem';
  Cert.PrivateKeyFile := '/etc/myserver/example-com.key';
  Server.Ssl.SniCertificates.Add(Cert);
end;

Certificate renewal without downtime. Let's Encrypt certificates expire every 90 days. Restarting your server to pick up a renewal means dropping connections. Instead, call ReloadCertificates — the files are re-read and applied to new connections, while listeners and established connections keep running:

  // e.g. from a certbot deploy hook, or a nightly timer
  Server.ReloadCertificates;

If the new files can't be loaded, an exception is raised and the current certificates stay in use — a bad renewal can't take your server down.

WebSockets on Linux — finally

Sparkle has supported WebSockets since 2024, but only on Windows. The socket server brings them to Linux, using the exact same API and TWebSocketMiddleware, over both ws and wss:

type
  TWsEchoModule = class(THttpServerModule)
  public
    constructor Create(const ABaseUri: string); override;
    procedure ProcessRequest(const C: THttpServerContext); override;
  end;

constructor TWsEchoModule.Create(const ABaseUri: string);
begin
  inherited Create(ABaseUri);
  AddMiddleware(TWebSocketMiddleware.Create);
end;

procedure TWsEchoModule.ProcessRequest(const C: THttpServerContext);
var
  Upgrader: IWebSocketUpgrader;
  WebSocket: IWebSocket;
  Msg: IWebSocketMessage;
begin
  Upgrader := C.Item<IWebSocketUpgrader>;
  if Upgrader = nil then
  begin
    C.Response.StatusCode := 400; // not a WebSocket upgrade request
    Exit;
  end;

  WebSocket := Upgrader.Upgrade;
  repeat
    Msg := WebSocket.Receive;
    case Msg.MessageType of
      TWebSocketMessageType.Text:
        WebSocket.Send('echo: ' + Msg.Text);
      TWebSocketMessageType.Close:
        begin
          WebSocket.SendClose(WebSocketStatusCodes.NormalClosure);
          Break;
        end;
    end;
  until False;
end;

Idle WebSocket sessions are exempt from the read and keep-alive timeouts, so long-lived push connections just work.

Static files in the same binary

A REST API usually ships with something to serve: an SPA, a few images, a landing page. Use the standard TStaticModule and it all lives in one process:

uses
  Sparkle.Module.Static;

  Server.AddModule(TStaticModule.Create('http://localhost:8080/', '/var/www/myapp'));

Routing is by path, exactly as in every other Sparkle server — so your API on /tms/xdata, a WebSocket endpoint on /ws, and static files on / coexist happily on one port.

Handlers that wait — sized automatically

Here's the part that usually bites people who write their own server, and the reason a naive thread pool is not enough.

A worker thread is busy for as long as your handler runs. Handlers that return immediately need very few threads. But a handler that waits — for a database query, for an API call to another service — holds its worker while doing nothing at all. With a fixed pool, your throughput is capped at workers ÷ handler duration, no matter how idle the machine is. Sixteen threads and a 200 ms query means 80 requests per second, on a machine that's 95% idle.

The socket server sizes its pool on its own:

• It starts with WorkerThreads threads (default: twice the processor count).
• Whenever requests are waiting for a worker, it adds threads, up to MaxWorkerThreads (default: 256).
• Threads above the minimum exit after 30 seconds without work, so the pool shrinks back when the load drops.
• Requests that are handled immediately never grow the pool — a CPU-bound server keeps running on its initial threads.

In most cases the defaults are simply correct and there is nothing to configure. You set these properties when you want a different shape — most commonly to put a ceiling on threads that compete for a limited resource:

  // A database-bound API against a pool of 50 connections:
  // more workers than that would only queue up waiting for a connection.
  Server.WorkerThreads := 16;
  Server.MaxWorkerThreads := 50;

Built to face the internet

The socket server is designed to be exposed directly, without a reverse proxy in front of it, so the defensive parts are built in rather than left to nginx:

• Slowloris protection — HeaderReadTimeout bounds how long a client may take to send its request head (and the TLS handshake). Slow clients never occupy a worker thread: the event loop reads request heads, and only complete requests are handed to a worker.
• Overload protection — MaxConnections caps simultaneous connections and MaxQueuedRequests caps how many requests may wait for a free worker. Beyond that, the server answers 503 and closes, rather than accumulating unbounded latency.
• Size limits — the Limits property (TSocketServerLimits) bounds the request line, individual headers, header count, total head size and body size, with the correct status code for each violation (413, 414, 431, 400).

  Server.Limits.MaxBodySize := 50 * 1024 * 1024; // reject bodies over 50 MB
  Server.KeepAliveTimeout := 30000;

You can still put nginx or Caddy in front if you want HTTP/2, HTTP/3, rate limiting or centralized certificates — just add the forward middleware so your handlers see the original client address and scheme.

The RAD way

If you build your servers by dropping components on a data module, there's a new dispatcher component: TSparkleSocketDispatcher. Connect your TXDataServer, TSparkleStaticServer or other server components to it through their Dispatcher property, set Active to True, and you're running.

The underlying server object is available through Server for anything you need to configure from code:

uses
  Sparkle.Comp.SocketDispatcher;

  SparkleSocketDispatcher1.Server.Ssl.CertificateFile := '/etc/myserver/cert.pem';
  SparkleSocketDispatcher1.Server.Ssl.PrivateKeyFile := '/etc/myserver/key.pem';
  SparkleSocketDispatcher1.Active := True;

Deploying: a binary and a systemd unit

Deployment is about as simple as it gets. Compile for Linux 64-bit, copy the binary, and register it as a systemd service in /etc/systemd/system/myserver.service:

[Unit]
Description=My Sparkle server
After=network.target

[Service]
ExecStart=/opt/myserver/myserver
Restart=always
User=myserver
Group=myserver

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now myserver

Binding to ports below 1024 needs privileges — either run as root, or grant just the one capability the binary needs:

sudo setcap cap_net_bind_service=+ep /opt/myserver/myserver

How fast is it?

Fast enough that the network is usually the interesting part, not the server.

Measured on a 4-vCPU Ubuntu 24.04 VM with wrk, 30-second runs (as always with benchmarks: your hardware, handlers and payloads will differ):

Throughput scales monotonically with concurrency — there is no dip at moderate connection counts, and no connection resets in the stress runs.

A fair-play note on that Indy column: those are tuned Indy numbers. Indy does not set TCP_NODELAY on accepted connections, so with shipping defaults Nagle's algorithm and the TCP delayed-ACK timer hold small keep-alive responses back by ~40 ms, capping each connection at roughly 24 req/s. The benchmark disables Nagle per connection so the comparison measures the servers rather than a missing socket option. The socket server sets TCP_NODELAY on every accepted socket itself, so there is nothing to remember and no such trap.

More interesting than the raw numbers is the blocking-handler behaviour, because that's what a real XData API does all day. With handlers that wait 500 ms and 256 concurrent connections, the socket server served 509 req/s — against 504 for an equivalent Node.js server and 510 for Go, on the same box in the same session. That's 99–100% of the arithmetic ceiling (concurrency ÷ latency): the elastic worker pool means a Delphi server waiting on a database is not at a disadvantage against the stacks people usually reach for.

And how stable is it?

Speed is the easy half. A server that is exposed to the internet has to survive the boring part — days of load, misbehaving clients, and load it cannot possibly serve. The socket server was built and measured with that in mind:

• It doesn't leak. Through hours of continuous benchmarking, thread count and open file descriptors tracked concurrency exactly and returned to baseline between runs, with resident memory flat at the end of the campaign.
• No errors where it counts. Every database-shaped scenario — handlers waiting 50 ms to 500 ms, at 64 and 256 concurrent connections — completed with zero errors and zero dropped connections, on both Linux and Windows.
• Predictable at the limit. When load exceeds what the configured workers can serve, it answers 503 and closes rather than queueing without bound, so an overloaded server stays responsive and recovers as soon as the spike passes. That threshold is yours to size, via MaxWorkerThreads and MaxQueuedRequests.
• Malformed and hostile input is handled by design, not by luck. The HTTP parser was fuzzed, and every limit violation maps to a defined status code rather than an unhandled exception.
• It runs the same test suite as every other dispatcher. The TMS BIZ automated tests execute against the socket server on Linux and Windows, so the module, middleware and WebSocket behaviour you rely on is verified on it — not just on the Windows dispatchers.

And on Windows, too

The socket server is cross-platform: it runs on Windows 32-bit and 64-bit as well, with the same code, the same properties and the same behaviour. (Internally it uses epoll on Linux and WSAPoll on Windows, which is about the only thing that differs.)

On Windows the Http.Sys-based server remains the recommended choice for high-load production servers — it's kernel-mode and integrates with the Windows certificate store. Reach for the socket server on Windows when:

• your application can't run administrative setup. Http.Sys needs netsh URL reservations and certificate bindings; the socket server binds plain sockets and needs none, so it runs under any user account.
• you want identical behaviour on both platforms — develop on Windows, deploy on Linux, with one configuration and no surprises.
• you prefer PEM certificates with SNI and hot reload over the Windows certificate store.

One more thing for Linux

A related fix in the same release removes another long-standing Linux annoyance: Sparkle now registers JOSE cryptography providers backed by OpenSSL 3, so JWT tokens signed with RSA (RS256/384/512) and ECDSA (ES256/384/512) work on distributions that no longer ship the legacy OpenSSL 1.x libraries — Ubuntu 22.04 and later, among others. This is what lets a TMS Sphinx server using RSA-signed tokens run on a modern Linux box. The providers are registered automatically and fall back to the previous implementation when OpenSSL 3 isn't available, so existing applications need no changes.

Conclusion

The socket server makes Linux a first-class deployment target for Delphi HTTP servers:

• One self-contained binary — no Apache, no nginx, no third-party libraries to install or keep updated.
• Everything a public-facing server needs — HTTPS with SNI and zero-downtime certificate reload, WebSockets, static files, keep-alive, chunked encoding, and built-in protection against oversized, slow and excessive requests.
• Fast, and steady under load — including the case that matters most, handlers that wait on a database.
• Nothing to rewrite — existing Sparkle, XData and RemoteDB modules run on it as they are.
• Cross-platform — the same server, the same configuration, on Linux and Windows.

It is now the recommended way to deploy TMS Sparkle, TMS XData and TMS RemoteDB servers on Linux.

A complete demo — dynamic endpoint, static files, WebSocket echo and optional HTTPS, in a single program that builds for both platforms — ships in the Sparkle distribution under demos/SocketServer.

To learn more, read the full Socket Server documentation and the what's new list, and visit the TMS Sparkle product page.

Build a Summer City Walking Tour Guide with TMS AI Studio, TMS FNC Maps and TMS FNC UI Pack

         Use coupon code :on the online order form to activate the discount! 

• TMS AI Studio for AI-generated tour content and speech
• TMS FNC Maps for geocoding, directions, markers, route drawing and GPX export
• TMS FNC UI Pack for the polished cross-platform user interface

From a City Name to a Personalized Walking Tour

• Museums
• Historical Places
• Architecture
• Parks & Nature
• Entertainment
• Shopping
• Food & Drinks
• Art & Galleries

                       

Screen for entering city or retrieve current location                                    The visualization of the calculated route
and categories of places you want to visit

AI That Calls Back into Your Delphi Code

• The POI name
• A short description
• The POI category
• A Wiki URL

This is achieved by a tool call that is setup:

var
  p: TCloudAIParameter;
begin
  CloudAI.Tools.Add;
  CloudAI.Tools[0].Name := 'addtourplace';
  CloudAI.Tools[0].Description := 'Add a POI name, description and Wiki Page URL for the walking tour to the list';
  CloudAI.Tools[0].OnExecute := ToolExecuted;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'POI';
  p.Description := 'The name of the POI';
  p.Required := true;
  p.&Type := ptString;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'Description';
  p.Description := 'A brief summary description of the POI';
  p.Required := true;
  p.&Type := ptString;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'Type';
  p.Description := 'The type of the POI from the list ' + CategoriesList([low(TPOICategory)..high(TPOICategory)]);
  p.Required := true;
  p.&Type := ptString;

  p := FCloudAI.Tools[0].Parameters.Add;
  p.Name := 'WikiURL';
  p.Description := 'The URL of the Wiki page of POI';
  p.Required := true;
  p.&Type := ptString;
end;

This gives the application clean, structured data instead of free-form text that still needs to be parsed afterwards. That is an important difference when building real applications: the AI becomes part of the workflow, while the Delphi application remains in control of how the data is stored, shown and processed.

Putting the Route on the Map

// build the waypoints array and ask the directions service to calculate a route 
// from starting place back to starting place with all waypoints in between
var
  i: integer;
  org: TTMSFNCMapsCoordinateRec;
begin
  org.Longitude := Places[0].Coord.Longitude;
  org.Latitude := Places[0].Coord.Latitude;
  SetLength(wp, Places.Count - 1);

  for i := 1 to Places.Count - 1 do
  begin
    wp[i - 1].Longitude := Places[i].Coord.Longitude;
    wp[i - 1].Latitude := Places[i].Coord.Latitude;
  end;

  FDirections.GetDirections(org, org, nil, '', nil, false, tmWalking, wp, true);
end;

A UI That Feels Like a Mobile Travel Companion

• Enter a city
• Pick one or more POI categories
• Generate the walking tour
• Review the generated places
• Open the map
• Tap a marker or list item for more information
• Listen to the description at the POI
• Export the route when needed

Let the Smartphone Speak at the POI

Why This Demo Matters

• Use AI to generate contextual, personalized content.
• Use mapping components to turn that content into real-world navigation.
• Use a rich cross-platform UI toolkit to make the experience easy and pleasant.

• Tourism apps
• Museum and campus guides
• City event applications
• Hotel concierge tools
• Conference venue guides
• Real estate neighborhood explorers
• Outdoor activity planners

A Productive Combination for Delphi Developers

Conclusion & share your city walks!

Free sample

Why build reports around a DataGrid?

Many application reports begin in exactly the same way: connect to a database, execute a query, inspect the result, make a few visual decisions, and send the data somewhere else. The destination may be a browser, an API, a PDF archive, a CSV import, or an Excel workbook, but most of the work before that point is identical.

A traditional report designer is invaluable for invoices, labels, and highly structured documents. For operational reports, however, a data grid is often the more natural authoring surface. Users can see the records immediately, sort a column, apply a filter, and export exactly the view that answers their question.

That idea is the basis of the FNC Database Generator, a free source-included FireMonkey sample built with TMS FNC UI Pack. It connects a FireDAC dataset to TTMSFNCDataGrid and turns the active renderer into a small multi-format reporting engine.

One adapter turns a dataset into a report view

TTMSFNCDataGridDatabaseAdapter connects the dataset to the DataGrid renderer. The important detail is almAllRecords: the report renderer receives the complete result set, not only the records currently needed for the visible viewport.

Adapter.DataSource := DataSource;
Adapter.Renderer := Grid.Root;
Adapter.AutoCreateColumns := True;
Adapter.LoadMode := almAllRecords;
Adapter.Active := True;

The grid then adds the interaction that users expect from a professional data tool:

• Alternating row bands for easier scanning.

• Single-row selection with a restrained highlight.

• Conditional formatting that marks overdue orders in red and paid orders in green.

• Stretching columns for a clean desktop layout.

The FMX application keeps connection, preview, and every export action in one focused workspace.

Conditional Formatting

In the sample, some rows are highlighted. This is due to conditional formatting based on the data. The code shows how to apply certain rules while working with dynamic data.

procedure TMainForm.GridGetCellLayout(Sender: TObject;
  ACell: TTMSFNCDataGridCell);
var
  SavedRecord: Integer;
  StatusField: TField;
begin
  if (ACell.Row < Grid.FixedRowCount) or not Adapter.CheckDataSet then
    Exit;

  StatusField := Query.FindField('Status');
  if not Assigned(StatusField) then
    Exit;

  SavedRecord := Adapter.DataLink.ActiveRecord;
  try
    if Adapter.SetActiveRecord(ACell.Row) then
      if SameText(StatusField.AsString, 'Overdue') then
      begin
        ACell.Layout.Fill.Color := $FFFFEEEE;
        ACell.Layout.Font.Color := COLOR_RED;
      end
      else if SameText(StatusField.AsString, 'Paid') then
        ACell.Layout.Font.Color := COLOR_GREEN;
  finally
    Adapter.DataLink.ActiveRecord := SavedRecord;
  end;
end;

HTML and CSV: native renderer exports

The DataGrid renderer already knows which rows and columns belong to the active view. HTML and CSV therefore need only one call each. The generated HTML includes CSS classes for the grid appearance, while CSV applies the configured delimiter and quoting rules.

Grid.SaveToHTMLData(FileName, TEncoding.UTF8);

Grid.Options.IO.Delimiter := ',';
Grid.Options.IO.QuoteEmptyCells := True;
Grid.SaveToCSVData(FileName, TEncoding.UTF8);

The browser-rendered HTML export carries the same columns, banding, and paid/overdue colors.

JSON: the visible grid as structured data

JSON is deliberately implemented as a small serializer in the demo. It walks the renderer instead of the original query, skips hidden and filtered rows, and uses the fixed header row as property names. This means the JSON payload describes the same report view that the user sees.

for Row := Renderer.FixedRowCount to Renderer.RowCount - 1 do
  if not Renderer.IsRowHidden(Row) and
     not Renderer.IsRowFiltered(Row) then
  begin
    RowObject := TJSONObject.Create;
    for Column := 0 to Renderer.ColumnCount - 1 do
      if not Renderer.IsColumnHidden(Column) then
        RowObject.AddPair(
          TTMSFNCDataGridData.ValueToString(Renderer.Cells[Column, 0]),
          TTMSFNCDataGridData.ValueToString(Renderer.Cells[Column, Row]));
    Rows.AddElement(RowObject);
  end;

The exported document also includes the report name, generation time, and source connection string. In a production application you can replace the last item with a friendly connection name when credentials or host details should not leave the application.

PDF: a report that is ready to share

TTMSFNCDataGridPDFIO handles pagination and draws the DataGrid using the FNC PDF engine. The sample adds a report title, a generated timestamp, page numbers, fit-to-page scaling, and repeated fixed rows.

PDFIO.DataGrid := Grid;
PDFIO.Options.Header := 'SALES PERFORMANCE REPORT';
PDFIO.Options.Footer := 'Generated ' +
  FormatDateTime('dd mmm yyyy, hh:nn', Now);
PDFIO.Options.PageNumber := pnFooter;
PDFIO.Options.PageNumberFormat := 'Page %d';
PDFIO.Options.FitToPage := True;
PDFIO.Options.RepeatFixedRows := True;
PDFIO.Save(FileName);

Because the PDF exporter uses the renderer, the output carries across the navy header, banded rows, and conditional colors. Longer result sets automatically continue on additional pages.

A rendered page from the verified PDF: report title, repeated DataGrid header, styled rows, footer timestamp, and page number.

Excel, in both generations

The sample treats .xls and .xlsx as two real formats rather than two file extensions for the same binary content.

• XLS: TTMSFNCDataGridExcelIO exports the current renderer to the classic Excel binary workbook format and preserves cell properties.

• XLSX: the optional FlexCel build converts that styled XLS workbook into a genuine modern Office Open XML workbook.

ExcelIO.Renderer := Grid.Root;
ExcelIO.DataGridStartRow := 0;
ExcelIO.DataGridStartCol := 0;
ExcelIO.Options.ExportOverwrite := omAlways;
ExcelIO.Options.ExportCellProperties := True;
ExcelIO.XLSExport(IntermediateXLS, 'Sales report');

Workbook := TXlsFile.Create(IntermediateXLS, True);
try
  Workbook.Save(FileName, TFileFormats.Xlsx);
finally
  Workbook.Free;
end;

In a core build the toolbar marks the command XLSX*; selecting it gives a clear dependency message instead of producing an XLS file with a misleading extension. A FlexCel build exports an intermediate XLS, converts it to ZIP-based XLSX, and removes the intermediate file. FlexCel is required on the build machine, but users do not install it separately when the finished application is deployed without runtime packages.

The FlexCel configuration produces a genuine XLSX workbook, shown here opened in Excel with the complete header, first column, banding, and conditional colors intact.

A UI designed for the workflow

The FMX form is intentionally more than a row of test buttons. It uses a dark product header, separate connection and SQL cards, a clear export toolbar, a large report canvas, and a persistent status area that reports the record count and output path. The result feels like a small utility rather than a component test.

All generated files are written to an Output folder beside the executable. This keeps the sample database and every generated report together with the active demo build. When deploying to a platform that protects application bundles, place the application in a writable location or redirect this folder to platform-specific application storage.

Natural next steps include saved report definitions, query parameters, a column chooser, chart summaries, scheduled exports, or cloud upload. The important architectural point stays the same: the DataGrid renderer is the reusable report model, while each output format is a focused adapter around it.

If TMS FNC is installed through Smart Setup, the product family can be installed from the command line:

tms self-update
tms install tms.fnc.*

Conclusion

The FNC Database Generator sample shows how far a database-aware DataGrid can go beyond on-screen browsing. One FireDAC query becomes an interactive report, and one renderer becomes HTML, JSON, PDF, CSV, XLS, or XLSX.

For operational reporting, internal tools, exports, and data handoffs, this approach stays pleasantly direct: query the data, make the grid look right, and let the current view become the report.

In the previous blog post, we showed you how to use the TTMSFNCFilterDialog, allowing users to build complex filter expressions through a guided interface.

That works well when users intentionally want to create or modify a filter.

However, many modern applications don't expose filtering as a separate action anymore.

Think about a webshop.

You don't open a filter editor or write filter expressions.

You simply select a category, choose a few brands, move a price slider and perhaps select a delivery date.

The results update automatically while you interact with the page.

That is exactly the idea behind TTMSFNCFilterView.

Filtering Without Filter Expressions

The goal of the Filter View is simple.

Instead of asking users to create filter expressions, the application presents familiar controls that contribute to the filter automatically.

The user never needs to know that a filter expression exists.

Every interaction updates the underlying TTMSFNCFilterBuilder, keeping the filter synchronized in the background.

For example, instead of writing:

Country = 'Belgium' AND Age > 18

The user simply:

• Selects "Belgium" from a ComboBox
• Moves a slider to 18

The Filter View generates exactly the same filter structure that we built manually in the previous blog posts.

The Filter View Architecture

Internally, every filter control contributes one or more expressions to the same FilterBuilder.

This means every control is responsible for a small part of the complete filter.

For example:

• a CheckBox can generate a Boolean expression
• a ComboBox selects one value from a predefined list
• a DatePicker filters on a date
• a RangeSlider creates both a minimum and maximum value
• a ValueEdit combines a comparison operator with user input

The FilterBuilder combines all these expressions into one structured filter.

Because the same FilterBuilder is used, everything we discussed in the previous blogs still applies.

• Nested groups
• Different output formats
• Parsing
• Validation

The Filter View simply becomes another way of building that same filter.

Built-In Filter Controls

The Filter View already contains a rich collection of controls that cover many common filtering scenarios.

• CheckBox
• CheckGroup
• RadioButton
• RadioGroup
• ComboBox
• DatePicker
• TrackBar
• RangeSlider
• ValueEdit

Each control automatically updates its own FilterExpression whenever its value changes.

Because every control understands the type of data it represents, the resulting filter remains consistent.

Configuring Expressions

Every filter control has an associated FilterExpression.

This determines which part of the data the control affects.

Typically this consists of:

• the field name
• the field type
• the comparison operator
• an optional default value

For example, a ComboBox filtering countries can be configured like this:

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

Whenever the selected value changes, the filter expression is updated automatically.

Likewise, a CheckBox could represent:

Active = True

without requiring any additional filter logic.

Building Complex Filters Naturally

Individual controls are useful, but real applications often require multiple filters working together.

Suppose we want users to filter:

• Employees from Belgium
• Who are currently active
• And joined after 2020

Instead of writing:

Country = 'Belgium'
AND Active = True
AND JoinDate > EncodeDate(2020,1,1)

The interface simply contains:

• a Country ComboBox
• an Active CheckBox
• a Join DatePicker

Every control updates its own expression, while the FilterBuilder combines them into one filter automatically.

Grouping Controls

Just like FilterBuilder supports nested groups, the Filter View can visually group controls together.

A GroupPanel represents one filter group.

Groups can use either AND or OR operators.

This makes it easy to recreate even complex nested filter structures without exposing that complexity to the user.

More Than Built-In Controls

The built-in controls cover many common scenarios, but they are certainly not the limit.

TTMSFNCFilterView was designed to be extensible.

You can integrate virtually any existing control by using the TTMSFNCFilterViewControlContainer, or register your own controls directly with the Filter View.

This allows domain-specific interfaces without sacrificing the underlying filtering logic.

We've covered custom controls in more detail in a separate blog post, but the important takeaway is that the Filter View isn't limited to its built-in controls.

One Filter, Multiple Outputs

Because the Filter View builds upon the same FilterBuilder introduced earlier in this series, everything remains compatible.

You can still:

• Generate filter text.
• Assign the result to a DataSet.
• Validate rows.
• Filter object collections.
• Generate different filter formats.

The only difference is how the filter is created.

Instead of code or dialogs, the user simply interacts with the application.

Why Use TTMSFNCFilterView?

The Filter View provides a different user experience compared to a traditional filter dialog.

• Users interact with familiar controls instead of filter expressions.
• Filtering updates automatically while users work.
• The FilterBuilder stays synchronized behind the scenes.
• Complex filtering logic becomes easier to understand.
• The same filtering logic can still be reused throughout the application.

For many applications, this feels much more natural than asking users to open a separate filter dialog.

Next Step

So far in this series, we've focused on creating filters.

But filtering can do much more than determining which records are visible.What if the same filtering logic could also change colors, hide controls, enable actions, or modify properties?In the next blog post, we'll introduce TTMSFNCFilterRulesManager, where filter expressions become the starting point for dynamic application behavior.

For years, FNC Maps has given VCL and FMX developers one component that talks to Google Maps, Azure Maps, HERE, Mapbox, Leaflet and half a dozen other providers through a single, consistent API. It is one of those components people forget is doing something hard, because it never feels hard to use.

We kept getting the same question from teams who had also moved part of their stack to .NET: "can we get that in WinForms, WPF, MAUI or Blazor?"

Today we are revealing the answer: TMS.NET Maps, a full port of the FNC Maps engine to .NET, and it is now open for a closed beta.

• One control, four platforms — WinForms, WPF, .NET MAUI and Blazor all share the exact same async API, so the code you write for a desktop app largely drops straight into a mobile or web one.
• Twelve mapping and location providers — Google, Azure Maps, HERE, Mapbox, Leaflet/OpenStreetMap, OpenLayers, Apple MapKit, TomTom, GeoApify, OpenRouteService and IPStack, selectable at runtime.
• Batteries included — markers, shapes, clustering, heatmaps, drawing tools, popups, custom overlays and companion services for geocoding, directions, elevation, places and IP location all ship in the box.

Why we built it

FNC Maps exists because Delphi developers should not have to learn a different mapping SDK for every provider, and should not have to rewrite their map code when they move a project from VCL to FMX, or from desktop to mobile.

The same argument holds even more strongly in .NET, where a single company might have a WinForms line-of-business app, a WPF dashboard, a MAUI field app and a Blazor customer portal, all wanting the same "show a map, drop some pins, draw a route" functionality. Nobody wants to learn four different map SDKs, four different marker models and four different event systems to do the same thing four times.

So TMS.NET Maps is not a new component with a similar name — it is the same design philosophy as FNC Maps, rebuilt natively for .NET: one shared core, one control per platform, and a WebView-based rendering layer underneath so every provider's own JavaScript map engine can be used as-is, at full fidelity.

One shared core, one control per platform, every provider's own map engine underneath.

What's inside

Everything below is implemented once, in the shared core, and works identically across all four platforms.

• Overlays — markers (with custom icons, drag support, drop-in animation and info windows), polylines (including geodesic lines and directional arrow symbols), polygons, rectangles and circles, all with full add/update/remove/clear APIs.
• Clustering — group large marker sets into clusters automatically as the user zooms, with configurable clustering options.
• Heatmaps — render weighted point data as a heat layer, independent of markers.
• Drawing tools — let end users draw shapes directly on the map and get notified when they finish.
• Popups and custom overlays — anchored popups for ad-hoc content, plus HTML element containers you can dock to map corners or center for custom UI (legends, search boxes, mini dashboards).
• A genuinely rich event model — click, right-click, double-click, hover, drag and move events are exposed consistently for the map itself and for every overlay type (markers, polylines, polygons, circles, rectangles).
• Companion services — Geocoding, Directions, Elevation, Places, StaticMap and Location (IP-based geolocation) ship as separate packages you can use standalone, even in a backend service with no map UI at all. A dedicated RouteCalculator service builds on top of Directions for turn-by-turn, navigation-style scenarios. (More on these below.)
• Runtime provider switching — call one method to swap the entire map from, say, Google to Azure Maps, and your markers, lines and shapes carry over automatically.

A map in ten lines

Here is the entire "hello world" for the WPF control — the WinForms, MAUI and Blazor versions of this are almost identical.

<Window x:Class="QuickStart.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:maps="clr-namespace:TMS.Maps.Wpf;assembly=TMS.Maps.UI.Wpf"
        Title="TMS.NET Maps Quick Start" Height="600" Width="900">

    <maps:MapControl x:Name="Map"
                      Provider="Google"
                      ApiKey="YOUR_GOOGLE_MAPS_KEY"
                      CenterLatitude="40.7128" CenterLongitude="-74.0060"
                      ZoomLevel="10"
                      MapReady="Map_Ready"/>
</Window>

private async void Map_Ready(object? sender, EventArgs e)
{
    await Map.AddMarkerAsync(new MapMarker(new Coordinate(40.7128, -74.0060), "New York")
    {
        Options = new MarkerOptions { Animation = MarkerAnimation.Drop }
    });

    await Map.FitToMarkersAsync();
}

That is a fully interactive map, panned and zoomed to fit its markers, with zero JavaScript written by you.

Bonus: swap providers without losing your overlays

Because every provider implements the same shared core, switching the backing map engine at runtime is one call — useful for A/B testing a provider, falling back when a key is missing, or just giving end users a choice.

// Markers, lines and shapes carry over to the new provider automatically.
await Map.SwitchProviderAsync(Providers.Azure, azureMapsApiKey);

Beyond the map: the service layer

Not every scenario needs a rendered map. An ASP.NET Core API validating an address, a nightly batch job geocoding a CSV of customers, or a console tool generating a static map thumbnail for an email — none of that needs a MapControl, a WebView, or a reference to any UI framework at all.

Six of the seven companion packages are plain service classes: construct one with a provider and an API key, call an async method, get a typed result back.

using var geocoding = new GeocodingService(Providers.Google, apiKey);

var result = await geocoding.GetAsync("1600 Amphitheatre Parkway, Mountain View, CA");
if (result.Success)
{
    var match = result.Data.First();
    Console.WriteLine($"{match.FormattedAddress} -> {match.Coordinate.Latitude}, {match.Coordinate.Longitude}");
}

Directions follows the same shape, and returns distance, duration and the route geometry:

var directions = new DirectionsService(Providers.Google, apiKey);

var routes = await directions.GetAsync(
    new Coordinate(52.3676, 4.9041),   // Amsterdam
    new Coordinate(50.8503, 4.3517));  // Brussels

var route = routes.Data.First();
Console.WriteLine($"{route.Summary}: {route.Distance / 1000:F1} km, {route.Duration / 60} min");

The full lineup:

• Geocoding — address to coordinates and back, via GetAsync(string address) or GetAsync(Coordinate). Backed by Google, Azure, HERE, Mapbox, OpenRouteService and GeoApify.
• Directions — routes between two points or a full waypoint list, returning distance, duration, turn-by-turn steps and the route geometry. Backed by Google, Azure, HERE, Mapbox, OpenRouteService, GeoApify and TomTom.
• Elevation — elevation for a single coordinate or a whole list at once, for terrain profiles. Backed by Google and OpenRouteService.
• Places — search, autocomplete and place details through one GetAsync(PlacesRequest) call. Backed by Google, Azure, HERE, Apple MapKit, GeoApify and TomTom.
• StaticMap — either a ready-to-use image URL (GetUrl, synchronous, no HTTP call) or the actual image bytes as a Stream (GetAsync) — for emails, PDFs or thumbnails with no map control anywhere in sight. Backed by Google, Azure, HERE, Mapbox and TomTom.
• Location — IP-based geolocation, no GPS and no user permission prompt required. Backed by Google and IPStack.

Every one of these takes only a Providers value and an API key to construct — no map control, no WebView, no reference to WinForms, WPF, MAUI or Blazor at all. They are just as at home in an ASP.NET Core service or a background job as in a UI project.

RouteCalculator: more than a thin wrapper

RouteCalculator sits a layer above Directions. Instead of a one-shot "get me a route," it models a stateful, editable route plan: build it, add waypoints, undo and redo changes, save and reload it, and optionally have it render and update itself on a live map.

var directionsService = new DirectionsService(Providers.Google, apiKey);
var routeCalculator = new RouteCalculatorService(directionsService);

var plan = await routeCalculator.CalculateRouteAsync(
    "Amsterdam, Netherlands",
    "Brussels, Belgium");

foreach (var segment in plan.Data!.Segments)
    Console.WriteLine($"{segment.Distance / 1000:F1} km, {segment.Duration / 60} min");

Pass it an IRouteRenderer — the built-in MapRouteRenderer does this for a MapControl — and the same plan draws and updates itself on screen as it changes. Nothing about the service itself requires that you do so, which is what makes it equally useful in a delivery-planning backend with no map in sight.

Why this matters

• One API to learn, not four — the same marker, shape and event code works on desktop, mobile and web.
• No provider lock-in — pick Google today, add Azure or HERE tomorrow, or offer a free no-key option with Leaflet or OpenLayers, without rewriting your map code.
• A WebView-based renderer means every provider's own map engine runs at native fidelity, not a reimplementation of it.
• Geocoding, directions, elevation, places and location services are available standalone, so backend-only projects can use them without any UI dependency at all.
• It carries forward everything FNC Maps developers already trust, now available to .NET teams.

Join the closed beta

TMS.NET Maps targets .NET 10 and is available today as a private, evaluation-only closed beta covering WinForms, WPF, MAUI and Blazor.

Sign up on the TMS .NET page and we'll get you access to the private package feed, the getting-started guide, and a direct channel to the team building it. Your feedback is exactly what will shape the 1.0 release.

TMS.NET Maps brings the same cross-platform mapping engine behind TMS FNC Maps to WinForms, WPF, .NET MAUI and Blazor — one API, twelve providers, and every overlay, clustering, heatmap and routing feature you'd expect, in native .NET. Sign up for the closed beta.

In the previous blog post, we explored how TTMSFNCDataSetFilterDialog and TTMSFNCFilterDialog allow users to build complex filters through a guided visual interface instead of manually writing filter expressions.

While screenshots explain the concepts, seeing the components in action often gives a much better idea of how quickly complex filters can be created.

That's why we'd like to share the following demonstration, showcasing both dialogs in a real application.

What You'll See

The video starts with a quick demonstration of the TTMSFNCDataSetFilterDialog, showing how a filter can be created for a TDataSet without manually writing the filter expression.

It then continues with a more extensive demonstration using TTMSFNCFilterDialog together with TTMSFNCDataGrid, where you'll see how users can create even complex nested filters through a visual interface.

Among other things, the video demonstrates:

• Selecting fields instead of typing field names.
• Showing only operators that are valid for the selected field type.
• Building nested AND and OR groups visually.
• Generating the correct filter expression automatically.
• Applying the resulting filter directly to the grid.
  
  

New Since TMS FNC UI Pack 7.2

The video was recorded before the release of TMS FNC UI Pack 7.2.

Since then, another useful feature has been added.

The TTMSFNCDataSetFilterDialog is now also available as the design-time editor for the Filter property of a TDataSet.

Instead of manually typing a filter expression in the Object Inspector, you can now simply open the visual editor, build the filter, and have the generated filter text written back to the dataset automatically.

This makes creating dataset filters during development considerably easier, especially for more complex expressions.

The Same FilterBuilder Foundation

Both dialogs are built on top of the same TTMSFNCFilterBuilder introduced earlier in this series.

Whether the filter is created programmatically, through the visual dialogs, or later through the Filter View, the same structured filtering model is used throughout.

This means the generated filter can still be:

• assigned directly to a TDataSet
• parsed back into a visual representation
• validated against your own data
• generated in different filter formats
  
  

What's Next?

So far we've looked at building filters either through code or through a dialog.

In the next part of this series, we'll remove the dialog altogether.

Instead, users will simply interact with checkboxes, combo boxes, sliders and date pickers while the filter is updated automatically in the background using TTMSFNCFilterView.

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

It is the cleanest way yet to let a language model touch a real system. And a database is the obvious first system to reach for.

But a database is also the scariest one. You do not want an over-eager model running DROP TABLE on production data.

So in this post we build an MCP server in Delphi that is generic, configurable and safe:

• generic, because it works with any engine FireDAC can reach
• configurable, because you decide what the AI is allowed to do
• safe by construction, because in read-only mode there is literally no tool that can write

Everything below is a real, compiling demo from the TMS MCP SDK. The JSON in the result blocks is copied straight from a live run against SQL Server.

The shape of it

One executable sits between the MCP client and FireDAC.

It owns the database connection for its whole lifetime, enforces an access mode and a SQL-safety check on the way in, and turns result sets into JSON on the way out.

Because it is driven by a connection string and by FireDAC's engine-agnostic metadata API, the same binary speaks to SQLite, PostgreSQL, MySQL, SQL Server, Oracle, Firebird and ODBC.

One binary; the connection string decides the engine.

A server in thirty lines

The entry point is almost boring, which is the point.

You link the FireDAC driver units for the engines you want to support, create a TTMSMCPServer, register your tools, and run. Start wires up the stdio transport automatically, and Run is the blocking JSON-RPC loop.

uses
  // Link every engine you want this build to speak to:
  FireDAC.Phys.SQLite, FireDAC.Phys.PG,   FireDAC.Phys.MySQL,
  FireDAC.Phys.MSSQL,  FireDAC.Phys.ODBC, FireDAC.Phys.Oracle,
  FireDAC.ConsoleUI.Wait, // headless: no VCL/FMX forms
  TMS.MCP.Server, TMS.MCP.Transport.STDIO,
  DBConnectionManager;

var
  Server : TTMSMCPServer;
begin
  Manager := TDBConnectionManager.Create(Config);   // owns the connection
  Manager.Connect;

  Server := TTMSMCPServer.Create(nil);
  Server.ServerName := 'FireDACMCPServer';
  Manager.RegisterTools(Server);   // db_info, list_tables, run_query, ...

  Server.Start;   // stdio transport
  Server.Run;     // blocking read/dispatch/write loop
end.

Everything interesting lives in TDBConnectionManager. Let's build it up piece by piece.

One connection string, any engine

FireDAC's TFDConnection can be configured entirely from a connection string, such as DriverID=...;Server=...;Database=....

That is the whole trick. Whatever the user passes, FireDAC parses it and dispatches to the right driver.

We add auto-reconnect for resilience and, in read-only mode, flip the datasets read-only as a second line of defence.

FConnection := TFDConnection.Create(nil);
FConnection.LoginPrompt := False;

// The one line that makes this engine-agnostic:
FConnection.ConnectionString := AConnStr;   // "DriverID=PG;Server=...;Database=..."

FConnection.ResourceOptions.AutoReconnect := True;
if FMode = amReadOnly then
  FConnection.UpdateOptions.ReadOnly := True;   // belt and braces

FConnection.Connected := True;

Safety, in three modes

The single most important design decision is that capability follows mode.

A read-only server does not merely refuse writes. It never registers a tool that could write, so the assistant never sees one.

• readonly (default): SELECT and metadata only. It exposes db_info, list_tables, describe_table and run_query. No mutation tool exists.
• readwrite: adds run_statement for INSERT, UPDATE, DELETE and MERGE. Schema changes are still refused.
• full: also allows DDL (CREATE, ALTER, DROP, TRUNCATE) and the otherwise-blocked statements. For sandboxes and admin work.

That is enforced by a single conditional at registration time:

// Read tools are always registered.
FServer.Tools.RegisterTool('run_query', 'Execute a read-only query', ToolRunQuery);

// The write tool only exists when the mode permits it:
if FConfig.AccessMode <> amReadOnly then
  FServer.Tools.RegisterTool('run_statement', '...', ToolRunStatement);

Belt and braces, though. Even a registered tool runs its SQL past a classifier first.

We blank out comments and string literals so the leading keyword cannot be smuggled past us, then map it to a category and check it against the mode. Multi-statement stacking, such as SELECT 1; DROP TABLE users, is rejected unless you explicitly opt in.

function Classify(const ASQL: string): TSQLCategory;
var KW: string;
begin
  // StripSQL blanks comments and quoted text before we read the keyword
  KW := LeadingKeyword(StripSQL(ASQL));
  if      (KW='SELECT') or (KW='WITH') or (KW='EXPLAIN') then Result := scRead
  else if (KW='INSERT') or (KW='UPDATE') or (KW='DELETE') then Result := scWrite
  else if (KW='CREATE') or (KW='ALTER')  or (KW='DROP')   then Result := scDDL
  else Result := scDangerous;   // ATTACH, PRAGMA, EXEC, GRANT, ...
end;

Every call is classified and mode-checked before FireDAC sees it.

Turning a row into JSON

The other half of the job is marshalling.

A TField becomes the right JSON type. Numbers stay numbers, booleans stay booleans, dates go out as ISO-8601, and binary columns are base64-encoded with a size cap so a large blob cannot flood the transport.

case AField.DataType of
  ftBoolean:
    Result := TJSONBool.Create(AField.AsBoolean);
  ftInteger, ftLargeint, ftAutoInc:
    Result := TJSONNumber.Create(AField.AsLargeInt);
  ftFloat, ftCurrency, ftBCD, ftFMTBcd:
    Result := TJSONNumber.Create(AField.AsFloat);
  ftDate, ftDateTime, ftTimeStamp:
    Result := TJSONString.Create(FormatDateTime('yyyy-mm-dd"T"hh:nn:ss', AField.AsDateTime));
  ftBlob, ftVarBytes, ftBytes:
    Result := TJSONString.Create(TNetEncoding.Base64.EncodeBytesToString(AField.AsBytes));
else
  Result := TJSONString.Create(AField.AsString);   // strings, GUIDs, memos
end;

Point it at a SQL Server table with one column of every awkward type, and it round-trips cleanly:

• DECIMAL(12,2) becomes 1234.56
• MONEY becomes 9999.99
• BIGINT becomes 9000000000
• BIT becomes true
• DATETIME2 becomes "2026-07-03T14:25:36"
• UNIQUEIDENTIFIER becomes "{0CFED1EF-...}"
• VARBINARY (small) becomes a base64 string
• VARBINARY (300 KB) becomes "<binary 300000 bytes...>"
• NVARCHAR(MAX) becomes "café, naïve, 日本語"

Wiring it into Claude Desktop

While our MCP server will work fine with any AI client, we present here the steps to make the integration with Claude Desktop.
Build the project (it is a plain Win32 console app), then add an entry to Claude Desktop's claude_desktop_config.json. The connection string and mode live in args:

{
  "mcpServers": {
    "SQLSandbox": {
      "command": "C:/.../FireDACMCPServer.exe",
      "args": [
        "-conn=DriverID=MSSQL;Server=localhost;Database=MCPSandbox;OSAuthent=Yes;ODBCAdvanced=TrustServerCertificate=yes",
        "-mode=readonly"
      ]
    }
  }
}

A note on SQL Server and ODBC Driver 18. Driver 18 encrypts by default and validates the server certificate, so against a local instance you will hit "the certificate chain was issued by an authority that is not trusted". Pass it through with ODBCAdvanced=TrustServerCertificate=yes. FireDAC's own TrustServerCertificate parameter is not forwarded to ODBC, only ODBCAdvanced works.

What the assistant sees

On connect, the client asks for the tool list. Notice the annotations. Read tools carry readOnlyHint, the write tool carries destructiveHint. Those hints help the model reason about what is safe to call unprompted.

{ "tools": [
  { "name": "db_info",        "annotations": { "readOnlyHint": true, "idempotentHint": true } },
  { "name": "list_tables",    "annotations": { "readOnlyHint": true } },
  { "name": "describe_table", "annotations": { "readOnlyHint": true } },
  { "name": "run_query",      "annotations": { "readOnlyHint": true } }
] }
// run_statement is absent - this is a read-only server.

Now a real conversation. You ask a question in plain English:

"Which customers are in Springfield, and what have they ordered?"

Claude picks the run_query tool and writes the SQL itself:

SELECT c.Name, o.Id, o.Status
FROM Customers c
JOIN Orders o ON o.CustomerId = c.Id
WHERE c.City = 'Springfield';

Under the hood, that call returns a tidy envelope: columns, rows, a count, and a truncated flag so the model knows if it hit the row cap.

{
  "columns": [ { "name": "Id",   "type": "ftInteger" },
               { "name": "Name", "type": "ftWideString" },
               { "name": "City", "type": "ftWideString" } ],
  "rows": [ { "Id": 1, "Name": "Acme Corp", "City": "Springfield" } ],
  "rowCount": 1,
  "truncated": false
}

The model reads that back and answers in words, for example that Acme Corp in Springfield has two orders, one shipped and one still pending.

And if the model gets ambitious on a read-only server, the guards answer for it, clearly enough that it can correct itself:

// run_query "DROP TABLE person"
"run_query only accepts read-only statements. Use run_statement instead."

// run_query "SELECT 1; DROP TABLE person"
"Multiple SQL statements in a single call are not allowed."

// tools/call run_statement
"Unknown tool: run_statement"

Bonus: ask for the connection at runtime

What if you do not want to bake the connection string into the config at all?

Start the server with no -conn and it comes up unconnected, exposing a single connect tool. Once the AI (or you, through it) supplies a connection string and a mode, the server connects and the database tools appear through a tools/list_changed notification.

// connect { driver_id: "MSSQL", server: "localhost",
//           database: "MCPSandbox", mode: "readwrite" }
{
  "connected": true,
  "driverId": "MSSQL",
  "accessMode": "readwrite",
  "message": "Connected. The database tools are now available."
}

On a bidirectional transport you would use MCP elicitation to pop a form for the credentials. Over stdio, a connect tool is the clean, universal equivalent.

Why this matters

Wrapping a database as an MCP server this way gives a few practical advantages:

• The assistant explores the schema itself through list_tables and describe_table, so you do not hard-code anything.
• The access mode is a single switch that decides read-only, read-write or full.
• In read-only mode there is no mutation tool at all, not just a blocked one.
• The SQL classifier stops statement stacking and out-of-mode statements before they reach the database.
• Every value comes back correctly typed, including dates, decimals, GUIDs and binary data.
• The very same binary becomes a Postgres, Oracle or SQLite agent just by changing the connection string.

The important part is that the safety is structural. The mode decides which tools exist, and the classifier is the backstop behind them.

Get the demo

The full source, FireDACMCPServer.dpr and DBConnectionManager.pas, is available on GitHub: github.com/tmssoftware/Database-MCP-Server.

A prebuilt Windows executable is included in the repository, so you can register it with Claude Desktop and try it against your own database right away, without compiling anything.

Clone it, point it at your own database, and start in readonly. You can always turn the dial up later.

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.