Leaderboard

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 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.

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

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!

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.

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.

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

Wasting terajoules for basic refactorings, welcome to 2025

It is as relevant, if not more (there are other results further down the article from other sources) than one person telling me how well AI worked for them. This entire "I need a dedicated sub forum for AI to discuss AI" debate is getting ridiculous - if you have something to share, then do so. If we find out that one or multiple sub forums are containing loads of threads about a certain topic, a mod might create a new sub and move them there - easy as that.

I've just released MARS v.1.6: among features and fixes, there is a new integration of WebBroker's FCGI support (added with Delphi 13, released yesterday). Read more at: https://blog.andreamagni.eu/2025/09/delphi-13-florence-and-mars-curiosity/ Sincerely, Andrea

There's also a fairly rich documentation available online.

Something wrong with this one.?

There have been some significant improvements to TJSONSerializer. The following have been added: TJsonValueSerialization = (Always, ExcludeDefault, ExcludeSpecial, ExcludeAll); TJsonReferenceHandling = (None, Preserve, IgnoreCycles, ErrorOnCycles); Also the following related issues I had submitted have been fixed. TJSONSerializer support for Null value and default value handling. - RAD Studio Service - Jira Service Management TJsonObjectWriter,Container should be declared as TJSONAncestor - RAD Studio Service - Jira Service Management TJsonDictionaryConverter cannot serialize TDictionary descendent classes - RAD Studio Service - Jira Service Management Allow empty keys in JSON objects - RAD Studio Service - Jira Service Management In addition the a couple of my older issues have been addressed: https://quality.embarcadero.com/browse/RSP-41987 TDockTabSet does not DPI scale the images displayed - RAD Studio Service - Jira Service Management Note that, for some reason, the list of issues fixed in New features and customer reported issues fixed in RAD Studio 13.0 - RAD Studio does not include some of the above fixed issues. So the list does not appear to be comprehensive.

But at least you can not satisfy someone every time.

In my opinion, creating new forums should only be considered if there is sufficient activity around this topic (regardless of whether it's AI or anything else), which I don't currently see.

I was interested in the new AI chatbot that Emba are offering, which was announced in the webinar yesterday. It's at: https://www.embarcadero.com/radaicompanion The concept is that it is an AI bot that has been tweaked to target Emba products, Delphi, C++Builder etc. Anyway, after a recent question on SO I asked: Does the VCL have a TagObject property? The answer was a little disappointing: Yes, the VCL does have a TagObject property. It is available in the FMX.Types.TFmxObject class, which is part of the FireMonkey (FMX) framework, not the VCL. The TagObject property allows you to store any TObject value. I mean it gets there in the second sentence, but starting with Yes is poor. Classic AI people pleaser stuff! I then gave it some more recent SO questions and I have to say it did a good job. I'm quite interested in this concept though, and we've been working on something similar for our product because it's too niche for standard bots to know how to answer tricky questions.

There is a video linked to from the MMX website, but that is in German. There are plans to do something like this in English using a more recent Delphi and MMX version, but the biggest problem is to find some time. While there also will be a workshop next Wednesday (also in German), there are plans to offer online workshops in English and German. Unfortunately there is no time frame for that.

No, this is not a good question to ask here. You should ask your favorite AI tool.

Is that a problem? If so, why? Yes - applications should not be installing root certificates into windows - the only scenario where I can see this being needed is when using self signed code signing certificates - which is happening more an more in enterprises for internal applications/scripts - especially ones where internet access is limited.

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

I doubt those organizations will meet the requirement for the Community Edition. CE is for individual (hobby) developers and start up companies.