Der schöne Günther

How do you actually detect that something has now gone wrong? Some component (like a DBGrid) displays a TDataSet that contains gobbledegook? Or is there more to detect it? How do you know it's memory corruption (like writing out of bounds), and not generally using a stale pointer? Have you tried compiling the application with a memory manager like full FastMM and enabled runtime checks?

Only the Typescript version, not the Delphi one, unfortunately.

For many, many years, I have used HFS. Not FTP, but HTTP. Just a portable .exe that hosts a http server that allows clients to download files and folders, and also upload. https://github.com/rejetto/hfs2 https://www.rejetto.com/hfs

If you just get a value, you call it getX(). If you retrieve a value from somewhere, it's called retrieveX(). If you calculate something, it's calcX(). That's the convention we've been using. I'm always glad I directly know, just by the name of it, whether it's a potentially blocking call, a simple getter or resource intensive calculation. A simple property X tells me nothing.

My first "serious" languages were C++, then Java. They both do not have properties. Maybe I'm biased. My brutally honest opinion: No one needs properties, especially with how limited they are in Delphi. Disadvantages include You cannot fine-grain access (public read access, protected write access) Delphi's code completion does not even show you if a property is writeable or not. You cannot pass them by reference (var or out parameters) like you can with fields It hides performance impacts. Is it just syntax sugar for directly reading a field? Or is it using a getter method that first locks something, then accesses a resource, calculates it, and then finally returns it? When performance matters, I do not know. I have to look at the implementation. They can do nothing a regular getter/setter cannot. Which you will have to write anyway. Tl;dr: Lose some advantages of using fields, lose some advantages of using getters/setters. Gain nothing, except saving three letters for "get" or "set".

On my last Delphi 11.0 installation, I completely cancelled the SDK installation. Delphi works fine. Maybe it's required for C++ Builder.

So looking at #395 Adding hcPATCH to THTTPCommandType · IndySockets/Indy@4813ee0 (github.com) that means my code for determining isPutOrPatch will now fail. I don't see any release numbers tied to the code, how can I know which Indy version will include this change?

On rare occasions, I also like to print source code on paper, and go through it, and make notes. However, I never print directly from the IDE. I copy the parts that I want and paste it into Visual Studio Code (because it has more advanced syntax highlighting). I then print from there, or paste it into a Word document and print from there. It takes a few seconds, but the results are top notch.

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?