Remy Lebeau

That error is raised by Indy's TIdMimeTable class when a file extension is being added that has already been added. But looking at Indy's default logic, although I do see several duplicates being added, the dupes are explicitly ignored when invoked by Indy itself. It is only when user code adds an extension that such error can be raised. And even so, TIdMimeTable is typically used only on-demand at runtime. never at design-time or at program startup.

It's a shame that Delphi does not have {$PUSH}/{$POP} directives like FreePascal has, that would clean up that code a bit, eg: {$PUSH}{$R-} TempInt := TempInt * 11; {$POP} This has already been requested in Delphi for many many years, but nothing ever came of it: QC #56908: Save and restore compiler directives with push/pop RSP-14045: {$BEGINOPT R+,Q-} ... {$ENDOPT} RSP-38847: Implement stack-like push/pop for compiler directives to preserve/restore state

FYI, you don't have to resort to that pointer hack if you enable the Writable Typed Constants compiler option.

I have a recruiter messaging me on LinkedIn offering a position for a Sr Software Engineer with Embarcadero RAD Studio experience: Anyone interested?

Probably 😒 Oh well...

Agreed. I've written many services, but I have written only 1 service that ever needed to run in dual GUI/service modes, and even then I eventually broke out the GUI into a separate project that communicates with the service. All the more reason to break out the GUI into its own project, to reduce the complexity of the service project. Not really. The IDE debugger can be attached to a service process. If I ever need to debug a service's startup code, I simply define a command-line parameter that I can issue in the SCM, and then I have the TService.OnStart event handler look for that parameter to invoke a pause until I attach the debugger to the process. Then I can debug the remaining startup code normally.

The recruiter hasn't replied yet with details...

Use HOW, exactly? Please be more specific and clarify the issue. Are you asking how to REPLACE Indy's TIdHTTPServer component with CSI's SimpleHttpServer component? If so, then obviously you can't use a TIdHTTPServer.OnCommandGet event handler as-is, you would have to re-write the handler code to meet CSI's requirements.

OK, I asked the recruiter for details and am waiting for a reply...

It is a pull request in Indy's GitHup repo, it has not been merged into Indy's main code yet: https://github.com/IndySockets/Indy/pull/299 Also see this recent discussion: https://github.com/mezen/Indy/issues/12

Did you copy/paste the error message as-is? There is no TScrollStyles type in the VCL, only TScrollStyle. Do you, by chance, have a custom/3rd-party unit in your code that defines its own TScrollStyles type? Perhaps also defines its own ssHorizontal constant of that type? Have you tried qualifying the enum values with the enum type? This is particularly important for ssHorizontal, which is defined by both of the System.UITypes.TScrollStyle and System.Classes.TShiftState types. if ( g.ScrollBars = TScrollStyle.ssBoth) or (g.ScrollBars = TScrollStyle.ssHorizontal) then if ( g.ScrollBars = TScrollStyle.ssBoth) then if ( g.ScrollBars = TScrollStyle.ssHorizontal) then

I've never worked with (or even looked at) Indy's LDAP classes before. But just looking at them right now, it appears that they are meant just for parsing/producing LDAP messages, not for receiving/transmitting them over TCP/UDP. So, you would likely need to handle the actual transmission yourself via TIdTCPClient or TIdUDPClient. For example, via TCP, connect a TIdTCPClient to an LDAP server, using an SSLIOHandler to handle SSL/TLS if needed, and then use TIdLDAPV3Encoder to prepare an LDAP message and save it to a TIdTCPStream to transmit it, and then use TIdLDAPV3Decoder with TIdTCPStream to receive messages. I have no idea if that actually works, but worth a try.

You still haven't shown the actual 'invalid compiler directive' error, or what code the error is referring to. That error is a compile-time error. But you said your code compiles and runs, it was just experiencing a runtime error instead, due to accessing an array out of bounds. So, what is the REAL problem here?

No. It is a remnant from Delphi's pre-Unicode days (going all the way back to Delphi 5, if not earlier). Even then, I question why it was ever added in the first place, since the API always returned the correct sizes to begin with. So, this will cause the caller to unnecessarily waste memory (if they enumerate subkey/value names afterwards) and should be taken out. Yes. The increment is not necessary. I have filed a bug report: RSP-41787: TRegistry.GetKeyInfo() doubles size of MaxSubKeyLen and MaxValueLen

TIdSMTP.Send() will call TIdSMTP.Authenticate() for you if authentication hasn't succeeded yet. If you try to send an email without being adequately authenticated, the server will report a failure, which TIdSMTP will raise as an exception. So really, there is little reason to check TIdSMTP.DidAuthenticate and call TIdSMTP.Authenticate() manually.

Only components increment GStack's usage count, utility classes do not. If you use GStack without creating any components, you are expected to call TIdStack.IncUsage()/DecUsage() directly, eg: TIdStack.IncUsage; // use GStack as needed... TIdStack.DecUsage; It doesn't hurt to call IncUsage()/DecUsage() if you are not sure whether they should be called. Just make sure they are balanced correctly. TIdStack is reference-counted, the 1st usage increment creates the instance, and the last usage decrement destroys it. I'll consider it for a future release when more design-breaking changes are being worked on.

In RAD Studio 11 (and since 10.3), only the Windows clang compilers support C++14 and C++17, the rest of the clang compilers support only C++11. See Modern C++ Features Supported by RAD Studio Clang-enhanced C++ Compilers for details. You should not have to do anything extra to enable C++17 by default when compiling for Windows. However, if you want to specify a specific standard version, you can do so manually in the project options via "C++ Compiler > Advanced > Other options > Additional options to pass to the compiler", eg: Also see How to set C++ language standard in C++ Builder on StackOverflow.

Technically, the correct name is Quality Portal. Quality Central was its predecessor.

AddStrings() has an overload that takes a TArray<string> instead of a dynamic "array of string" (even in 10.2 Tokyo), eg: type //TMyArrToStoreTheResulted = array of string; TMyArrToStoreTheResulted = TArray<string>;

That is an extremely old version of OpenSSL. You should be using openssl-1.0.2u-i386-win32.zip instead. Or, you can use this SSLIOHandler (work in progress) and then you can use a newer OpenSSL 1.1.x version instead.

If the root path already has a '\' on the end of it, you would be adding another '\' unnecessarily. Better to use IncludeTrailingPathDelimiter() instead, eg: LContinue := FindFirst(IncludeTrailingPathDelimiter(AFolderRoot) + APatternToSearch, faAnyFile, LSearchRecord) = 0; That comparison wont work correctly if the file name begins with any character that is lexicographically less-than '.' (a few of them are reserved, but many of them are not), namely: ! # $ % & ' ( ) + , - You need to check for '.' and '..' specifically instead, eg: if (LSearchRecord.Name = '.') or (LSearchRecord.Name = '..') then

Most servers are phasing out TLS 1.0, or already have, You should enable TLS 1.1 and TLS 1.2 as well: IdSSLIOHandlerSocketOpenSSL1.SSLOptions.SSLVersions := [sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2]; If you allow the Port to be configurable, you should also allow the UseTLS value to be configurable as well. There is a functional difference between utUseImplicitTLS vs utUsseExplicitTLS, so you should let your config indicate which to use on a non-default Port. As mentioned earlier, this is wrong. You need to use utUseImplicitTLS on port 465. Use utUseExplicitTLS on port 587 instead.

That zipped code was submitted by another user on a comment to the open PR in Indy's repo. I don't think that code was every merged into the repo where the PR originates from: https://github.com/mezen/Indy/tree/NewOpenSSL_PR (see https://github.com/mezen/Indy/issues/12).

Makes sense, because by default assigning a raw char* string to a UnicodeString has no way of knowing that the char string is encoded as UTF-8, so it assumes the string is encoded as ANSI instead. You might try using SetMultiByteConversionCodePage(), but it would be better to put the UTF-8 char sequence inside of a UTF8String object instead, eg: Edit1->Text = UTF8String("\xf0\x9f\x98\x82"); More generically, you can use RawByteString for handle any 'char'-based encoding: RawByteString str("\xf0\x9f\x98\x82"); SetCodePage(str, CP_UTF8, false); Edit1->Text = str; The RTL knows how to convert a UTF8String/RawByteString to a UnicodeString, and vice versa.

void __fastcall TForm1::Button1Click(TObject *Sender) { int x = Sysutils::StrToInt(Edit1->Text); // alternatives: // int x = Edit1->Text.ToInt(); // int x = std::stoi(Edit1->Text.c_str()); // int x = CSpinEdit1->Value; (using a TCSpinEdit instead of a TEdit) int y = Sysutils::StrToInt(Edit2->Text); // same as above... int sum = x + y; Label3->Caption = _D("The sum is ") + String(sum); // alternatives: // Label3->Caption = Sysutils::Format(_D("The sum is %d", ARRAYOFCONST((sum)) ); // Label3->Caption = String{}.sprintf(_D("The sum is %d", sum); // Label3->Caption = std::format(L"The sum is {}", sum).c_str(); // Label3->Caption = (std::wostringstring{} << L"The sum is " << sum).str().c_str(); }