Leaderboard

I for myself have never spent any time on this limitation, because I never had to (and probably never will) write that long string literals. Not only that the style guide is much stricter, it is just way less readable and thus I would never even think of doing that. In addition I would literally slap such code in the face of the developer presenting it to me. So better don't count me in here.

Hello everyone, sometimes it's good to have some good news in the forums and not always requests for support (even if these always improve technical skills). With Alexandria Rad Studio 10.3 I tried to enable TLS 1.3 support using a trunk version of Indy "https://github.com/mezen/Indy/tree/NewOpenSSL_PR" already described in issue 299. Uninstalled Indy from RAD STUDIO. Known Issues: - Lost support for FMX LivePreview (which I don't use). - Each time Rad Studio is closed, a runtime error is generated in the RTL library.... It is not recursive and when OK it disappears without a trace. I only close RAD Studio 1 or 2 times a day so it doesn't give me any problems. Care must be taken to remove all references to the original Indy sources in the RAD STUDIO LIBRARY path. To make it faster I saved the Windows registry with REGEDIT, edited with a NOTEPAD removing all references to INDY from the various keys and re-imported again with REGEDIT. I then entered the new paths (Core, Protocols, System, OpenSSL) of the new archive (unzipped in a directory on the disk) again in RAD Studio. Without touching anything, recompiling the old project with native OpenSSL 1.0.2 support worked perfectly. Then I modified the source by inserting a $DEFINE and some $IFDEFs to easily switch from version 1.1.1 to version 1.0.2 and vice versa. Version 1.1.1 actually only needs to specify the security keys (cipher) to use which are different from those of 1.0.2, and obviously have access to the two OpenSSL 1.1.1 DLLs. Everything works, with TLS 1.3 support and automatic downgrade to TLS 1.2 (as already reported in other TOPICs). Changing the $DEFINE and recompiling switches to the old "original" version with TLS 1.2 support with OpenSSL 1.0.2 All third-party components (obviously in source format) that use Indy work perfectly even with the new version once recompiled. I haven't tested all of my projects that use Indy to see if there were any issues, but the last 10 recompiled projects didn't produce any glitches. When I have some time I will try to reinstall RAD STUDIO from scratch and directly upgrade the Indy TRUNK in the original RAD Studio version just to see if by recompiling from there you can avoid LIBRARY PATH updates (except the OPENSSL which you have to add by hand) and above all if you manage to avoid the error when closing RAD Studio. Bye P.S.: the project is an HTTPS server directly derived from an Indy demo. It is online in Internet without any filter, protection or other with no issue at all after more than one years in two systems Windows desktop and Linux server (now the Linux server is not anymore online).

It opens up without problems here (RAD Studio 11.3). Edit: It opens via the Help menu entry. Do you expect it to open with F1 in the sources?

I have not used it in my programs, but SyncObjs.TEvent seems to be standard practice (and should be available on the Linux platform) Draft code: begin HttpServer := TMyHttpServer.Create; try HttpServer.Start; // now the server is processing requests // wait for terminate signal while MyEvent.WaitFor(MaxInt) <> wrSignaled do; // now terminate HttpServer.Stop; finally HttpServer.Free; end; end; The handler code for the http://webserver:port/stopserver URL would call MyEvent.SetEvent, and this will cause to leave the WaitFor loop.

I've now compared the log from Windows 7 and Windows 10.somethingsomething. I searched for "arw" in both logs. What stands out is that on Windows 7 the Explorer primarily uses the registry keys we're expecting; The documented ones. For example, it looks for (and finds) the property sheet handler in HKCU\Software\Classes\arwfile\shellex\PropertySheetHandlers and HKCR\arwfile\shellex\PropertySheetHandlers. On Windows 10 however, things are a bit different. Notably, it never looks for *arwfile\shellex\* Both Windows 7 and Windows 10 look for (and don't find) HKCU\Software\Classes\SystemFileAssociations\.arw\shellex\PropertySheetHandlers and HKCR\SystemFileAssociations\.arw\shellex\PropertySheetHandlers. They also read the more general keys HKCU\Software\Classes\*\shellex\PropertySheetHandlers, and HKCR\*\shellex\PropertySheetHandlers and Windows 10 additionally looks for HKCU\Software\Classes\Kind.Picture\shellex\PropertySheetHandlers and HKCR\Kind.Picture\shellex\PropertySheetHandlers. Apparently, the SystemFileAssociations keys are related to something called Association Arrays.

A tool to simplify source code search. Find where class or function is declared, where class descendants are declared, search only in comments or in strings, etc. Build for Delphi and written in Delphi from scratch. Detailed description: https://delphihtmlcomponents.com/codefinder.html