What’s coming next — what's in the pipeline?

That’s a really good question…

For the last two years, I’ve had nearly no spare time to work on my projects.

I’m still working on my FDK Version 2.0. As always, it’s hard to find the right moment to finally call it “ready.”

A trial version with demos in GetIt is still on my to-do list.

The formatter part has been extracted into my own source code formatter!
(I’ll explain more about that later).

The old version of my MVVM plugin is still not updated to the current version, which itself is also not yet ready!

I’ve been focusing a bit on AI work: my neural network is now running as a compute shader on the GPU. 

That’s nice… but being able to use a file from Hugging Face with it is not on the horizon yet.

The ORM part of my FDK is working nicely, and the connection (interface) to my MVVM (Model) is also functional. Some units are still missing, but overall, it looks promising.

For the web: My DelphiScript just-in-time compiler is running. With its ISAPI.dll implementation, you can mix HTML and DelphiScript in one file. There’s also a frame/template handler to create master pages to inherit from (works perfectly with Bootstrap).

For the never-ending story of converting my big non-Unicode application to Unicode, I’m building a source code analyzer (based on my tokenizer from the formatter project). This tool can find all ShortString method parameters. 

So, if I change a method signature from 

  var s: ShortString to const s: String, 

I automatically get a list of all calls to and from that method, including the necessary local variable changes.

The next step would be an auto-change plus background compilation to check the impact. Being able to also auto-generate a unit test on the fly (perhaps with ChatGPT) would be a dream.

Using my own NN for unit optimization is still in a pre-alpha state and not working as I’d like. 

Perhaps you already noticed: There is no formatter in Delphi 13 anymore. I never used the built-in formatter anyway, because I have my own rules developed over the last 40 years for formatting Pascal/Delphi code. No formatter has ever been able to follow my rules! 

That’s why I started writing my own formatter years ago.

My formatter must be able to:

• Format the default Borland style, and
• also fulfill my own very specific needs.

That’s why I created a plugin system for all parts of a Delphi unit. Want your own style for uses, var, or type declarations? Fine — just write a DLL that implements your needs. Your DLL will be called with all necessary information, and you only need to return the source well-formatted. Only the parts you want to change must be implemented! With this approach, any coding style can be supported.

I can explain my concept in more detail if needed. Perhaps I’ll even do a webinar on the topic. If you have spare time — and are not afraid of interfaces, pointers, and OOP — I could really use a helping hand. (But please, don’t contact me if you only want to peek at the source code!)

What I still need:

• More unit tests
• and lots of “bad vs. perfect” source examples in different coding styles for testing.

But that's all for today - more about the source formatter will be covered by another blog post later this year! 

Stay tuned!

Using UI bound threads - Delphi Summit 2025

Have you ever tried to use a thread in a Delphi form?

Then you know the problems!

This is just a brief overview of my talk about common problems. If you’d like to hear more, please attend my session at the Delphi Summit 2025 in Amsterdam.

To be clear: Threads are not a silver bullet that will automatically speed up your application wherever you use them. On the other hand, there are definitely cases where code must be executed in a background thread.

But where should we draw the line?

Writing to the UI is a clear boundary — of course — but for this we can use Queue or Synchronize, as most of us already know. However, using Synchronize in every case is almost like not using threads at all, because we still have to wait for the UI thread to do its job. This often results in worse performance, not better.

So, what is the right way to use threads in your Delphi forms?

In my talk, I’ll show examples of bad, not-so-bad, and good practices for using threads effectively.

After the event I will post more infos on this topic.