Der schöne Günther

Yes, and if the OCR yields Pascal code, it should automatically be compiled and executed. Except not really

It can add a lot of different things, and is highly customizable. It can be properly uninstalled. I find it to be of very high quality. @Uwe Raabe is maintaining it, maybe he can shed a bit of light how it works with C++ builder projects.

About a year ago, we updated one of our applications from 10.0 Seattle to 10.4 because we had to support HighDPI. I found it much easier than expected and was very pleased with the results. Some people believe all interface glyphs should be vector images instead of rasterized images. But I went with just storing the icons in different sizes and picking the right ones at runtime. All ImageLists were replaced by VirtualIamgeLists (or what they're called). After that, a few minor adjustments were necessary here and there, but not much. Only doing Windows, not sure how the development experience is on other platforms...

I found this handy "IDE Integration" window: My stupid question: If I only have one Delphi installation - How turn MMX back on, after disabling it?

I believe MMX does this with [Alt]+[Shift]+[Up/Down] Not tested, but it should work with C++ projects as well. MMX – speed up your Delphi development (mmx-delphi.de)

I never understood that either. In our code, it is handled like this: isPutOrPatch := (ARequestInfo.CommandType = THTTPCommandType.hcPUT) or ( (ARequestInfo.CommandType = THTTPCommandType.hcUnknown) and (ARequestInfo.Command = 'PATCH') ); As you can see, our REST server handles PUT and PATCH commands exactly the same. That is absolutely legit. The important part is to make it known to your API consumers.

What makes you think the CPU architecture of the machine that compiled the code is more probable than a simple regression in Delphi, from 10.4.2 to 11?

I tested in Delphi 10.0 Seattle where it was reproducible.

Put a breakpoint on your constructor TIBase<I>.Create(ABroker: I); begin FBroker := ABroker; end; ABroker is of type IFooBroker. Which absolutely makes sense, because for TIFoo, I is of type IFooBroker. However, you stuffed a reference of type IBaseBroker in there. The compiler shouldn't have let you.

You may want to look at the online documentation of Trim(..), emphasis by me: Source: System.SysUtils.Trim - RAD Studio API Documentation (embarcadero.com) You don't want to remove leading and trailing spaces, you apparently want to remove all spaces. Do this by "replacing" the spaces with an empty string, like myString := myString.Replace(' ', '');

There has been CVE-2014-0994 which Embarcadero published a hotfix for XE6, and a guide how to patch Vcl.Graphics.pas which is no longer online.

Why are you casting it? It makes no sense. In a TIFoo, FBroker is already of type IFooBroker. Your constructor of TIBaseExt<I> can just look like this constructor TIBaseExt<I>.Create(ABroker: I); begin inherited Create(ABroker); end; and therefore is not necessary at all. After removing the unnecessary casting, your code runs fine with no further changes.

That's the part I also did not understand. I don't see a gain to be had from developing Delphi applications on Windows 11, rather than Windows 10. Testing, of course, but that's going to be a throwaway VM anyway, so no need to worry.

They do not. The components from REST.Client.pas use, for example, TRESTHTTP from REST.HttpClient.pas.

For the most part, that's true, but I still remember how I spent most of my time porting own and 3rd party library code from 10.0 to 10.4: The ever-changing platform constants (Android32, Android64, iOS Simulator 32, iOS Simulator 64, ...), removal of class helpers and such and changing object properties and behaviour in FireDAC. Of course Delphi still has good backward-compatiblity, but I have the feeling they have let things slide a bit, for the last versions.

I know. I updated another project from 10.0 to 10.4 because of High DPI requirements. I was very happy with the result. It's just that it takes quite some time. And it's hard to justify spending time on updating your IDE when several other projects are already behind schedule again 😫

I am still on 10.0 Seattle for our main product. I'd hate to invest ten hours into carefully porting everything over to 11, only to find out "Nah, it's not ready yet". Maybe 10.4 would be a better choice, for the time being? In 11.0 Alexandria, there isn't anything too exciting in the RTL/VCL, but the IDE seems much improved (LSP, High DPI). Still undecided whether it's worth a shot. 🤔 No one knows when something like "11.1" could be dropped. Two months? Four months?

Why would you want to do that? Is a progress bar that vital? Why not just Go fetch progress On Result: paint progress bar Which is what @FPiette has outlined with moving the code that works with the JavaScript result into a seperate function and calling that one from your callback.

That might actually be possible. Accidently pressing F7 and then like "Uh, where am I?"

I'd not be surprised if Jamie didn't even know about the DPR file. How would you stumble across it, anyway? Right-clicking the project node and then finding "View Source" among two dozen other entries is not the most intuitive choice. I wish I still remebered how I first found it...

For your reference, here is the official Embarcadero documentation: Using DelphiLSP Code Insight with Other Editors - RAD Studio (embarcadero.com)

Linux is a compiler? 🤔

After our last endeavour with C++ Builder (see here: Does C++ Builder have code completion? - General Help - Delphi-PRAXiS [en] (delphipraxis.net)), we switched to VS Code. Have absolutely not regrettet it, and it's free.

I really enjoyed the video. What a great speaker.

Thank you for the video. I have recently picked up a C++ project and I actually enjoy it. But to be honest, I would rather build a big monolith app in Delphi than in C++.