Leaderboard

Even at work, where we have DevExpress and a number of other, chunky components installed the IDE loads our big legacy project up in less than 20 seconds. Add 10-15 more seconds of compiling and I am in debugging. Compare that with VS2019, which needs ~1min until IntelliSense kicks in, 1,5 min of compiling, 10 seconds of after-compilation-thinking and finally the project launches. I'm sure there are faster IDEs out there, but Delphi really isn't that bad from startup perspective.

Whilst @dummzeuch makes a good point about us (Embarcadero) wanting to keep a track on NDA breaches I can also see a flipside too which is more in line with what Tommi says. I've made a note to see if we can do something about providing information about compiler conditionals for future betas. Note that for those on the Beta we did allow component vendors and OSS projects to refer to things like "added compatibility for RAD Studio 12" in their release notes and commits as long as they did not refer to or expose any functionality which was specific to version 12. We want to balance the requirement for confidentiality (which is required for sometimes non-obvious legal or technical reasons) against trying to work with repos and Tech Partners to make life as easy as possible and to achieve compatibility as smoothly as we can. All MVPs and Tech Partners are regularly briefed and have several ways to get hold of me directly to ensure communications in both directions are as smooth as possible. For all our users, however, I am here to help be a bridge between Embarcadero's internal teams and all of you - it is quite literally my job. The best way to contact me is by email - ian.barker@embarcadero.com - and I will reply. I don't have all the answers but if I can't help directly, I will speak to colleagues and get the information from the people who do know it. We are listening. I am listening. I work with some truly remarkable, technologically passionate, talented people and we all want the product to be the best it can be, for you to get real value from using it, and for it to improve on an upward curve. That's not some kind of marketing hot air - it's a fact. In cases like this, the version number conditionals and so on being made available earlier, I thought we did this already but if that's not the case then let's see what we can do to improve on that in the future. Ian Barker. Embarcadero Developer Advocate.

It's been this way since Delphi 1. May as well not wish for a perfect "bug free" release before a new release comes. They'd be out of business. By now we should all understand that in order to benefit from bug fixes, we need to be on subscription, and we will have to upgrade to new versions with new bugs to watch out for. It is what it is. And I agree there are frustrating problems with the IDE, but frankly, most of what you described sounds a lot like a misbehaving package you have installed in the IDE. Especially since you say you get freezing while editing a form. If I were in your position I would be looking into figuring out what packages I may be using causing the IDE to be unstable. Remember, this is Delphi, all those design-time packages are DLLs loaded into the process of the IDE...

I agree with your conclusions and as said above, it's been the same with small improvements for years, so I just accepted it. I use these 'tricks' on a daily basis and consider them as part of development workflow: - highlighting words fails when code is folded, so I unfold all the code in unit I work on - use Kill task to kill LSP multiple times a day (https://stackoverflow.com/questions/74164165/is-there-a-way-to-setup-a-shortcut-to-re-run-the-delphi-lsp-instances) - when IDE starts acting up (bookmarks behaving strangely, watch window shows odd values, debugger hangs or slows down...) - restart IDE - search will likely start with Whole words checked, so check the status of Whole words regularly - 64 bit debugger requires special attention, so handle with care and don't be impatient and probably some more that I can't remember right now...

That's true for wonky edge cases, but I believe it is not the end customers job to write unit tests, especially when brand new features (which were used to justify a major version bump) struggle to get the basics done (LLVM-based compiler in C++ Builder, Delphi's LSP-based code completion, ...)

Short answer: No test case no fix. They do squash bugs when they have good descriptions and can be reproduced reliably. That makes it possible to see, understand, debug, fix and confirm the fix. The release and patch cycles are a bit slow, but it is what it is at this point. I have solved similar freezing issues before, but none were due to Delphi itself. Windows APIs tend to hang when trying to access non-existent network resources. Some old projects referenced common libraries on network shares on servers long gone but still in DNS. Strangest case was dead batteries in a RAID card which caused a Windows cluster to not use write caching - writes were only considered done when they hit the physical disks. Throughput dropped hilariously low for the hardware involved bottlenecking everything. That makes finding a freezing issue in Delphi itself harder without a way to reproduce as what a customer sees might not be due to Delphi itself. Seems like a catch-22 at this point: the freezing robs time from the same people we need to spend time on troubleshooting and trying to find a test case.

To be honest, I don't think any of this is new - It's been like this for several years now. I've just come to accept it. Over the last years, the IDE has gotten better, but just cannot compete with others , it's in a league of its own. For example, Visual Studio 2017 got its last bugfix in August 2023. Now imagine Delphi 10.2 still getting fixes...

Another approach would be to declare a TMessage descendant that the frame (and probably also any form) subscribes to during creation and unsubscribes from on destruction. Then you can broadcast this message when the language changes. uses System.Messaging; type TLanguageMessage = class(TMessage<string>); ... procedure TMyFrame.HandleLanguageMessage(const Sender: TObject; const M: TMessage); begin var msg := M as TLanguageMessage; SwitchToLanguage(M.Value); end; ... TMyFrame.Create FLanguageMessageID := TMessageManager.DefaultManager.SubscribeToMessage(TLanguageMessage, HandleLanguageMessage); ... TMyFrame.Destroy TMessageManager.DefaultManager.Unsubscribe(TLanguageMessage, FLanguageMessageID, True); ... NotifyLanguage TMessageManager.DefaultManager.SendMessage(nil, TLanguageMessage.Create('DE'));

You mean, that I am part of the beta? That is already known in public IAW Embarcadero: TZipFile Improvements in Delphi 12

AFAICT there are no ICODE in the map file for Delphi 64 builds. I solved the issue by not having an exception raised... And found the unit that triggered the exception through "Halt" and bisection from the unit list. There were 3000+ units in the whole project, but since it was during the initialization, bisecting didn't take long (add Halt to unit initialization, run and see if Halt reached or not, bisect and repeat)

While back I was pondering this situation again. When new Delphi comes out, it takes sometimes quite a long time we get it into the production, because have to wait some of the dependencies to release updates. We can fix those ourselves, but not always. IT can be pretty hard to familiarize the third party code that needs a fix (it maybe somewhat obscure considering the problem how to actually fix it). So I would propose that there would be some faster channel among of the Beta testers. Many of those in Beta provide some Open/Closed Source -code to others in community. If there would be common place to exchange those fixes, privately, and preferably also chat about how the beta is going etc, this would guess also lead to better bug reports and so on. Something like private Discord-server/channel (Or something similar) and/or forum similar to this. I mean that now people and companies doing beta test are separate islands of information that does not spread. And I think it would, in long run, help everyone. -Tee-

During the beta I use private forks of the public repositories to store all the changes. On release date the fork is merged into public. I don't distinguish code I may publish or not.

You can always tweak the source of DUnitX.Loggers.GUI.VCL.pas to your needs. Currently the code for saving is located in FormClose. Besides extracting it to a dedicated method, it can be inserted at the beginning of RunExecute. In Contributing.md you find instructions to make your enhancements available for all.

Don't do that; I don't know your code but I would think that very few strings actually need to be AnsiString. And even if your code already supports Unicode there can still be places that assume that SizeOf(Char)=SizeOf(Byte) and SizeOf(PChar^)=SizeOf(PByte^). Also, WideString is not the same as UnicodeString. WideString should generally only be used with COM. https://docwiki.embarcadero.com/RADStudio/Sydney/en/String_Types_(Delphi)

Low-level experienced, I'm still learning. Android has a layer of complexity above Linux kernel. Socket API on Android is the same a socket API on Linux. Before entering to TWSocket port, you should begin with the simplest program which open a TCP client socket with pure API, and send any string and wait for the answer, display it on a TMemo and then close. A simple TForm with a TButton and a TMemo will be enough. Use one of the server samples in ICS for Windows to connect to. You can find simple C-code for Linux that you can start with. If you are able to port this C-code to Delphi/FMX for Android, then you are probably ready to start porting ICS. If you want to discuss further, please open a new topic with proper subject to catch attention of interested peoples. Maybe some will help.

Hi, it would be great to have at least Android suport!

Well, 3rd party DLLs are not scary - OpenSSL, DB clients, chromium, etc. Sometimes they distribute the product as DLL so that any language could use it, even brainfuck. However there are plenty of native Delphi network components, commercial or free. I wouldn't use DLL for this without a significant reason. And if I would it would likely be cURL

The IFEND works in all versions. LEGACYIFEND ON only makes XE4+ accept only IFEND, too. That might be helpful to write code compatible with versions before XE4 when written and tested with newer versions only. So it is more like a safeguard for the developer, but code written like before XE4 will also compile in XE4+ without that LEGACYIFEND directive.

For the same reason they have ridiculous NDAs and don't have public betas; They are so stuck in the 90s that they think anyone still gives a damn.n They never understood how to build a community.

Works for me:

Please stop using VERxxx. It's been possible to do {$if CompilerVersion >= XX} since Delphi 6 or 7. It's so annoying having to edit the .inc files of various 3rd party libraries with each new version of Delphi because they're designed as if the latest version = the last version. Graphics.32 uses {$LIBSUFFIX AUTO} for the D11+ packages. The earlier packages are manually maintained by using a diff tool to keep them synchronized with a master. The master usually comes from the latest supported Delphi version. There's no way I'm wasting disk space on old versions of Delphi just to maintain the package files. I have the latest version, and the few versions required by my job, and that's it.

As one of the few lib devs that actually test their code on all supported Delphi versions I object - dproj files so often have incompatibilities in them. Yes, it is possible to have only multiple dproj files but only one dpk they refer to and put the libsuffix stuff into an inc file referencing that one on the dpr (have done that, works fine) but it is tedious. I rather copy the latest version when a new one comes out/is in beta. The more important thing imo is using forward-compatible defines in the code - it drives me mad whenever I compile some code in a newer version and it simply does not work because the code requires explicit defines because they are not done in a forward-compatible way.

This package madness really bothers. Especially knowing most versions doesn't differ at all.