Der schöne Günther

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

When you don't have hardware accelerated graphics (in your VM), that's just how it looks. No transparency effects, rounded corners and that kind of stuff. The basic rendering, however, is the same.

I also find unit tests are a great way to start getting familiar with foreign code. Like libraries from 3rd parties or your own company. You're new to it, you don't really have a feeling for it yet. So before just straight out using the code in your real life application, why not start with a few unit tests so you know you can trust it for your use cases? Maybe you can even contribute the tests back.

Use a profiler to find out what takes time and fix those parts 😎

It is what happens when the application that called ShellExecute did not provide a HWND of a foreground window. What is the value of your hndCaller ? Maybe you passed something like Application.Handle? Compare to GetForegroundWindow - Is your value the same?