Leaderboard

Another thing that worked surprisingly well for me is code review. I've had copilot complain about too little documentation in certain areas, point out a possible deadlock and suggest external libraries that saved me from reinventing the wheel. I haven't tried out reviewing Delphi code, though.

@David Schwartz Command line tool is now available: https://github.com/synopse/mORMot2/tree/master/src/tools/mopenapi (this is a good showcase how cross-platform and cross-compiler command line switches parsing could be done with mORMot) I will release a Win32 binary somewhere in the next days. Thanks for the feedback!

Thanks for the feedback! I ended up implementing a modified ROT13 algorithm with a custom alphabet, as shown in the code below. Initial tests indicate that it meets my requirements effectively. const ALL_CHARACTERS_CONSTANT = '!#$%&()*+,-./:;<=>?@[\]^_`{|}~0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюя'; function ROT13Encrypt(const Input: string): string; var idx, newIdx: Integer; halfLength: Integer; begin Result := ''; halfLength := Length(ALL_CHARACTERS_CONSTANT) div 2; for var i := 1 to Length(Input) do begin idx := Pos(Input[i], ALL_CHARACTERS_CONSTANT); if idx > 0 then begin newIdx := ((idx - 1 + halfLength) mod Length(ALL_CHARACTERS_CONSTANT)) + 1; Result := Result + ALL_CHARACTERS_CONSTANT[newIdx]; end else Result := Result + Input[i]; end; end; function ROT13Decrypt(const Input: string): string; begin // ROT13 decryption is the same as encryption in this case Result := ROT13Encrypt(Input); end;

Fixed the background colour problem by placing a TMSFNCPanel component on the TabItem and changing the FPDFControl.Parent to the panel name. The PDF now displays with a proper white background. Bill Zwirs

I've found that using Copilot with prompts like "Write Delphi code that does X on MacOS" is the fastest way to figure out what API to use and what units to import. The code may not compile but it doesn't need to -- such things typically take a lot longer to learn when wading through Apple Developer docs or trying to find it in Stack Overflow. Also questions like "What is the equivalent MacOS code to do what X does on Windows" and stuff like that, actually work pretty well to get me on the right track with minimal Googling or looking through SO.

I don't know if you can change that now, but when posting issue you need to use Share with Embarcadero customers to make it visible to others. See https://dalijap.blogspot.com/2024/04/delphi-121-new-quality-portal-released.html

I looked at MSQuic when it came out with a view to supporting it for ICS. For Linux, MSQuic uses a forked OpenSSL version, but SChannel for Windows. So MSQuic requires the latest Windows OS. From a Delphi perspective, MSQuic does not include HTTP/2 or HTTP/3 protocol support, and I'm not aware of any Delphi native implementations of either, only the nghttp2 DLL solution, and external DLLs are less than ideal for Delphi applications. I'd like to write a Delphi HTTP/2 implementation for ICS, but it really needs to be sponsored. I can not justify the time myself, rather work on more useful projects. To my knowledge, there are no functional benefits to HTTP/2 except performance with complex web applications with hundreds of elements on a page, and Delphi is not usually used for complex pages. The OpenSSL committee declined to accept the complex QUIC fork and instead added QUIC in a different way, the client version is available now, the server version has just started alpha testing. But without HTTP/2 for client and server, there seems little point in adding QUIC to ICS. Angus

Let me Google that for you... https://en.wikipedia.org/wiki/MsQuic https://github.com/microsoft/msquic/blob/main/docs/FAQ.md Enabling HTTP/3 support on Windows Server 2022 Troubleshooting HTTP/3 in http.sys

The problem is that Embarcadero provides base framework classes that satisfy very narrow usage and are not properly open for extension. Sometimes you need to change literally one line, to get the needed behavior, but there is no way to do that properly. So you need to resort to hacking into those classes. Protected opens up the class for needed extensions and still protects casual users from using implementation details and does not break encapsulation. Yes, if the implementation changes, you may need to update your code to match the changes, but you would need to do that regardless. Private is major PITA.

Encapsulation can be frustrating, but exposing everything means you're making promises. People's code will gain dependencies to everything that can be accessed or overridden. Which means you won't be able to change much (or fix) without breaking user code. Opening too much means code will sediment and become untouchable... In the case of the DX11 driver, it's obvious it was locked in the implementation section because whoever was working on it wasn't satisfied with it. Likely because he/she did not have time to tidy it up. It's essentially DX9 code with a light rewrite to DX11. I was able to hack it, but it was brittle. I'm now starting down the path of reimplementing it, which in the long term will open more possibilities (and hoping Delphi 12.2 doesn't wreak havoc on TContext3D, haha)