Leaderboard

Whilst there are many Delphi components for detecting changes to file system folders they suffer from serious limitations: typically they only allow you to monitor a single folder they do not support the monitoring of specific files they rely on the FindFirstChangeNotification API which gives no information about what has changed, requiring an inefficient search. I have created a new file system monitoring library that addresses the above limitations. Features: Easy to use, but also suitable for heavy duty monitoring Single unit with no external dependencies Allows monitoring folders and/or specific files Uses the ReadDirectoryChangesW API which provides information about what exactly was changed A single instance of the component can handle the monitoring of many folders and/or files Uses an I/O completion port for efficient handling of large numbers of requests A single thread handles all requests A different notification handler can be specified for each request You can have multiple handlers for each folder or file When you monitor folders you can specify whether you want to also monitor subfolders Installation: You do not need to install the library. Just download or clone the repo and add the source subdirectory to the Library path. Usage: procedure TForm1.FormCreate(Sender: TObject); begin // Create the IFileSystemMonitor interface FFileSystemMonitor := CreateFileSystemMonitor; // Monitor a directory FFileSystemMonitor.AddDirectory(TPath.GetTempPath, False, HandleChange); // Also monitor a specific file FFileSystemMonitor.AddFile('pathtoyourfile', HandleChange); end; procedure TForm1.HandleChange(Sender: TObject; const Path: string; ChangeType: TFileChangeType); begin with lvEventList.Items.Add do begin Caption := GetEnumName(TypeInfo(TFileChangeType), Integer(ChangeType)); SubItems.Add(Path); end; end; To stop monitoring a specific file or folder you use the following methods: function RemoveDirectory(const Directory: string; OnChange: TMonitorChangeHandler): Boolean; function RemoveFile(const FilePath: string; OnChange: TMonitorChangeHandler): Boolean;

Hi All I have released a new YAML Parser/Emitter library for Delphi XE2 or later. It is pure delphi code, tested with Win32 and Win64 but it should work for other platforms too (no winapi dependencies). Supports YAML 1.1 (partially) & 1.2 JSONPath queries with filter expressions Multiple Document streams. https://github.com/VSoftTechnologies/VSoft.YAML

If you are have a current subscription license, you can now download RAD Studio 13 from MyEmbarcadero. https://my.embarcadero.com/#downloadsPage You can also see What's New on the doc wiki: https://docwiki.embarcadero.com/RADStudio/Florence/en/What's_New

I haven't found a critical regression in the past 24 hours.

I have some issues with your implementation: IPv6 networks are not supported. The client request is needlessly wordy. The client broadcasts to 255.255.255.255 instead of to the subnet's actual broadcast IP. Some routers block traffic to 255.255.255.255 by default. In case the client is run on a machine with multiple networks installed (VPN, etc), there is no option to let the user decide which network to broadcast to. The client is using separate UDP sockets to send the request and read replies. You are forcing the client to receive on a specific listening port. The server is not sending its reply back to the real port that actually sent the request. Most routers will block this traffic if port forwarding is used. On the server side, always reply to the sending port. On the client side, either 1) let TIdUDPClient read replies on its sending port, or 2) let TIdUDPServer send the request on its listening binding. Use one or the other, not both. Doesn't use Indy's TIdStack.GetLocalAddressList() method to discover local networks (at least on Windows, as it may have issues on Android). Since your goal is to allow a TCP client to discover a server, I would opt to get rid of the TIdUDPServer on the client side, and just use TIdUDPClient by itself. Send a request, read a response, done. You don't need to make that process asynchronous with TIdUDPServer in most use cases. Using TIdUDPServer on the client side makes more sense if you want to discover multiple servers and then let the user choose between them, or to leave it open so servers can just broadcast their presence over time.

They will be unemployed because they know how to write code on their own? Yes, that makes perfect sense; Nobody wants to hire that kind of developers.

A simple, cross-platform demo (VCL + FMX) showing how to Super Fast LAN tethering in IPv4 network Automatically discover a server on the same LAN using UDP Broadcast with Indy components. 📌 Overview This project demonstrates a lightweight, zero-configuration **auto-discovery mechanism**: - The **Server** listens on a known UDP port (`3434`) for broadcast packets. - A **Client** (VCL or FMX/Android) sends a broadcast message (`Discovery|Hello...`) on port `3434`. - The **Server replies** directly to the client (on port `22049`) with its LAN IP address. - The **Client receives the reply**, extracts the server’s IP, and can then connect via TCP or continue communication. This makes it possible to build applications that can **find each other on the same LAN instantly** without manual IP setup. 🏗 Components Used - Indy UDP Components - TIdUDPServer. - TIdUDPClient. 2. - Cross-platform IP detection - Windows: `GetAdaptersAddresses` API - Android: `Java.Net.NetworkInterface` enumeration 3. - Thread-safe logging via `TThread.Queue`. 4. - Timer to control discovery message sending Loop All details has been added in my Github Repo here. Mit Licence: Please feel free to fork and improve & use it on your projects... Any remarks or suggestions are very wellcome here. -- thank you All.

They will be unemployed because AI will write all the code (or to rephrase: "Computers will program themselves") within a few years, as predicted already 30 years ago and time and time again afterwards. This time for real, we promise!

Maybe this would be a good occasion to learn Git then... Here's a quick intro I made for someone else that wanted to contribute a change to Graphics32: On Github Create a Github account: https://github.com/signup Fork the Graphics32 repository to your own Github account. This gives you a copy, on your own Github account, of the main repository where you can push your changes. On your local system Clone your own Graphics32 repository to your local system using a Git client. I recommend the Fork git client: https://git-fork.com/ Create a branch in your local repository. Commit your changes to that branch. Push the branch to your own Graphics32 repository. On Github Create a pull request on your Graphics32 repository. Specify the master branch at the main Graphics32 repository as the target, and your branch at your repository as the source. When Github notifies me that you have submitted a pull request I'll review the changes. Once I accept the pull request, the changes are merged into the branch you specified as the target branch.

Executor is one of my favorite projects started in 2007 and now over the summer I did a version 2 of it (Free on MIT license). If you remember old programs like Slickrun and Launchy it was originally a bit of a "techy" alternative to these, that besides launching things can also do clipboard stuff, manage active windows, manage running apps, text manipulation, a lot of hotkey trickery, built-in calculator etc. I develop in a bunch of languages, but I really love to develop in Delphi. It's where I can get idea to something working in the least amount of time, and the project compiles in 2 seconds, where if I'm sitting in Android Studio or Xcode I can fetch a new drink while waiting for the compiler. The project is using Delphi VCL. Originally Executor supported Windows all the way back to Windows XP. Which put quite some restraints on the development side. That minimum requirement was bumped up to Windows 7, also supporting both 64bit and 32bit, adding High DPI support as well. High DPI was a bit of a challange as Executor over those many years have had several skinning systems, some supporting borderless full alphablending on the main form with overlay full alpha blending images. These of course don't look pretty if trying to stretch a full alphablending image to 250% desktop scaling, and the author of the skin might not be active anymore, so you can't expect it to be updated with several resolution of the image assets (TVirtualImage, TVirtualImageList). Because of the skinning support and a lot of visual customization options, there's also a lot of paint events, ownerdrawing, hooking into WM_PAINT, WM_ERASEBKGND, WM_MOVE, CN_DrawItem etc. So I'm not using VCL styles, I tried a couple of times to use VCL styles, as it it would be nice to use for my settings form for dark mode etc. But with my limited experiments it was hard to isolate the VCL styles to only effect specific forms (the settings form and some other trivial forms), and it would then introduce a lot of side effects on the main form, where I'm doing a lot of custom visual stuff, seeming to collide with my code for this. Also in general I'm trying to not be depended on thrid party components and technologies, also caring about system footprint (cpu,gpu,mem,io etc). Some other nice challanges has been the 32bit and 64bit versions of Windows, as Executor can scan folders like the start-menu and other system folders, these are off-limit if not matching bitwise, and also various security restrictions was gradually added with each new version of Windows. Then scanning for UWP apps was another additional challange, as UWP seems like a bit of a "clunky add-on" that changed quite a bit in each version of Windows in terms of Windows API. Cheers and happy programming, Martin Website: https://executor.dk YouTube video:

I'm away at the moment and can't build an installer, but the current source code compiles with Delphi 13 and works with the 32 bit IDE.

And here we go: An installer for the Beta version of GExperts for Delphi 13: See the blog post.

But at least you can not satisfy someone every time.

I would say that is a good thing. This means in the future Delphi will still have a solid base of developers who know how to write their code.

Hi all, I have just uploaded the project EdgeAudio integrate mic capture, audio playback, a high‑pass filter, VAD, hysteresis, and a “Talkover” mode from Delphi, orchestrated through a bidirectional JS bridge inside TEdgeBrowser. The architecture centers on TEdgeAudioControl and TAudioSettings, applied in real time on the WebAudio side, with clean VCL integration (virtual host, typed events). Key points Clear architecture: capture (TEdgeAudioCapture), playback (TEdgeAudioPlayer with VAD/Talkover), filtering (THighPassFilter), and a WebView2 bridge; TEdgeAudioControl exposes settings and ready‑to‑use events. Extensible event engine: aggregates/routes JSON events (audio_play, audio_pause, audio_segment, etc.) via TEventEngineManager and IAudioEventHandler. Capabilities: tunable VAD (threshold/silenceMs/timeslice), Talkover with cooldown/ratios to avoid “ping‑pong,” playback/streaming (play/pause/seek/stop), setSinkId, volume boost, built‑in notifications/animations, and optional auto‑blocking of capture during playback. Quick start Install the EdgeAudioDesign.dproj package to register TEdgeAudioControl in the Palette. Two paths: (1) already have TEdgeBrowser → use the Edge.Audio unit; (2) drop TEdgeAudioControl. Copy the web/tools folders into your project and place WebView2Loader.dll (x86/x64) next to the executable. Sample projects (AudioEdgeTest1/2.zip) are provided; add “EDGEAUDIO\SOURCE” (and “OPENAI\SOURCE”) to your project search paths. Dependencies: Delphi 12+, WebView2 Runtime, and ffmpeg if you need audio conversion (configurable ffmpegPath). Learn more Diagrams, event flow, and extension points are detailed in the “Dev note – Architecture & Mechanics” sections and the deep‑dive in the repo. Preview

That's not quite true. They will usually allow you to continue your subscription if it run out not too long ago. But of course starting with the date it run out. Also, there are some special offers from time to time, where you can save part of the price for a new license. But for a while keeping the subscription active has been the cheapest way to update (if you can call that "cheap"). And every time you have to remove "platinum support" from the order. The one thing that has annoyed me the most, is that you need an active subscription to even download an install bugfixes.

My apologies for seeming sarcastic. I understand why. I also know it's not intended as sarcasm. Text is hard and it's hard to balance the line of making points. I think it is wonderful when Delphi adds features, quite genuinely, and the post said so. I edited to try to help that understanding, but the original said "congratulations", and that is sincere, and I retained that comment. It's hard reading that kind of reply, Daniel, and I don't know what to make of it. I think the best thing is to apologise because it's clear you are offended: and I am sorry for that. Let me pontificate a bit: I worry about language compatibility. There are multiple Pascals out there: Free Pascal, DWScript, etc etc. Yet Pascal is a small language. If Delphi ever added any other feature Oxygene or Free Pascal or anyone else already has, and chose to do so with different, incompatible syntax, that would be a significant statement. I use Python a lot, it gives me the same "feeling" as Delphi when I use it, I have talked about Python a lot to people with quite some enthusiasm, it has a ternary if, and that ternary if is inverted -- that structure is legit, and Delphi could have used it, and then imagine if we had two versions in Pascal! Far better to copy, when it's already been done -- with code existing for years, it's key to keep the same syntax compatible. Equally, there's so much the language could do. When it moves forward, I hope it does so in ways that copy the path that has been led by others. Perhaps that is the message in the blog post: keep going; there's more, follow. I would certainly prefer it's read that way. Please read again, I hope it's gentler. For this forum... that was not the message. I had intended to directly answer a thread about a language feature with a blog post showing a snippet of the language feature the OP asked for. Message: it is possible, look! I fully respect you don't want other implementations mentioned, and will respect that.

There are a stunning 5.4% not using AI at all, hooray, brave men and ladies

ICS is sort of ready for Delphi 13, but you will need the latest version of ICS V9.5 from the overnight zip or SVN. I recompiled all the ICS samples with D13 yesterday without problems. I've finished updating V9.5 but am still writing documentation, packaging and correctly typos. It should be released in a couple of days, but documentation always takes longer than one expects. So V9.5 won't be in GetIt for several days. A late compiler change during the beta meant the OverbyteIcsWinnls.pas unit gave a 'can not assign constants error', just need to move a var a couple of lines up the unit, Otherwise older versions of ICS will probably work provided the latest OverbyteIcsDefs.inc file is used, that was updated for Florence many weeks ago. Note the package version numbering has jumped from 23 for Delphi 12, to 37 for Delphi 13, so it now matches the compiler version 37. The status of C++ 13 and ICS is uncertain at the moment. I have not been able to build Win32 packages in C++ 13 that are OK in C++ 12.3, and which built OK in early betas of C++13. Maybe the packages need changes for C++ 13, but I am not a C++ developer, so will need assistance from those that actually use C++. I don't have much hope for C++ Win64x, the problems that prevent it being built in C++ 12.3 don't appear to be fixed in C++ 13. Angus

What you really need, really depends on each person. You obviously can't satisfy everone every time.

We have had these Delphi FMX guides available for a while, and I thought it could be useful to share them here: How to use Google Maps to determine the user's location in the Embarcadero Delphi FMX app: https://www.softacom.com/blog/how-to-use-google-maps-to-determine-the-users-location-via-embarcadero-delphi-fmx-app/ - shows how to access the user's coordinates and display them on a map. How to save and read data from Google Sheets in an Embarcadero Delphi FMX app: https://www.softacom.com/blog/development/how-to-save-and-read-data-from-google-sheets-in-an-embarcadero-delphi-fmx-app/ How to implement multi-touch in an Embarcadero Delphi FMX app: https://www.softacom.com/blog/development/how-to-add-multi-touch-to-an-embarcadero-delphi-fmx-app/ - shows how to add multi-touch drawing support How to use gestures in an Embarcadero Delphi FMX app: https://www.softacom.com/blog/development/how-to-use-gestures-in-embarcadero-delphi-fmx-app/ - shows how to handle swipe, zoom, and rotate gestures How to master FastReport in Delphi: https://www.softacom.com/blog/development/mastering-fastreport-in-delphi-dynamic-file-reporting-and-visualization/ – shows how to create dynamic reports and charts How to send email via an Embarcadero Delphi FMX app using the Gmail API: https://www.softacom.com/blog/development/sending-email-via-embarcadero-delphi-fmx-app-by-using-api/ How to generate images in an Embarcadero Delphi FMX app: https://www.softacom.com/blog/development/image-generation-capabilities-with-delphi-fmx-application-via-openai-api-dall·e-models/ - shows how to use OpenAI DALL·E for image generation

May I suggest "fluent interfaces" as an alternative to nested calls. Instead of using a record like a dumb data store that is only manipulated from the outside, you can put the methods that fiddle with the record's contents directly into the record itself and thus keep the code and the data closely together. Also, this enables one to use a so-called "fluent interface". Example: This is an example of a record that contains just one integer member, "data". In real life, you can make the record as complex as you want. type pMyrecord=^tMyRecord; tMyRecord=Record data:integer; Function Reset:pMyrecord; Function Add (x:integer):pMyrecord; Function Multiply (x:integer):pMyrecord; Function Divide (x:integer):pMyrecord; End; As you can see, all the methods in this record return a pointer, which simply points to the record itself. That is the "secret sauce" one needs to implement fluent interfaces. function tMyRecord.Add(x: integer): pMyrecord; begin data:=data+x; result:=@self; end; function tMyRecord.Divide(x: integer): pMyrecord; begin data:=data div x; result:=@self; end; function tMyRecord.Multiply(x: integer): pMyrecord; begin data:=data*x; result:=@self; end; function tMyRecord.Reset: pMyrecord; begin data:=0; result:=@self; end; Now the cool thing: All these methods can be concatenated and will be processed left-to-right. This produces very legible and compact code: procedure Test; var x:tmyrecord; begin x.reset.add(12).multiply(4).divide(2); end; (edit) Note that I didn't do a single heap allocation here, never manually passed the record as a parameter and never did a nested call. The data lives on the stack. If the record contains managed objects such as strings, these are disposed of automatically.

If you let your subscription lapse then they charge you full price for a new license because they are unscrupulous and hate their customers