Remy Lebeau

Which version of RAD Studio are you using? Can you provide a test project that reproduces the problem?

Are you sure your handler is actually hooked up to the event? Double-check the event is assigned in the Object Inspector at design-time, and also double-check the event is assigned at runtime, in case the DFM streaming is failing to assign it properly.

At program startup, detect the presence of the debugger (dynamically, or via a command-line parameter) and then use SetStdHandle() to replace STDIN with your own handle to a named pipe or anonymous pipe, and then write your desired debug data to that pipe. Or better, simply move your logic into a function that takes an input TStream as a parameter, and then decide whether you want to use a THandleStream for STDIN or a TStringStream or TMemoryStream for your debug data. On a side note - using a 'while (Position < Size)' loop is not a good idea. You should simply call Read() with a fixed-sized buffer, and let it tell you when it reaches the end of the stream, eg. SetLength(Buffer, SomeSize); repeat BytesRead := StdInStream.Read(Buffer, SomeSize); if BytesRead < 1 then Break; // do stuff until False;

Depends on how you are handling the pooling. But, once you have a connection, you should not need a CS as long as the queries for thwt connection stay in the same thread. Any data synching can be handled with DB-level transactions.

It is generally not a good idea to share DB queries across threads, unless you Synchronize() access to them. It is better to give each thread its own DB connection (pooled if needed) and unique query components.

Sure it's possible, but only if the code loads DLL functions dynamically via LoadLibrary()+GetProcAddress() at runtime (or the 'delayed' keyword at compile-time). I'm not familiar with ICS to know if it supports that.

That can be simplified to this: Result := V.IsArray; The ArrayData field is only meaningful for tkArray, it doesn't exist for tkDynArray. For tkDynArray, the ElType field is a member of TTypeData itself. However, it is nil if the array holds an unmanaged type. The actual element type is buried further in the TypeData. The TTypeData record has a DynArrElType() method to fetch it. In both cases, note that the element type is stored as a PPTypeInfo, so you need to dereference it when comparing it to another type. Try something more like this instead: function ValueIsValueArray(const V: TValue): Boolean; // this is pieced together from internal code in System.Rtti.pas... function GetArrayElType: PTypeInfo; var ref: PPTypeInfo; begin Result := nil; case V.Kind of tkArray: ref := V.TypeData^.ArrayData.ElType; tkDynArray: ref := V.TypeData^.DynArrElType; else Exit; end; if ref <> nil then Result := ref^; end; begin Result := V.IsArray and (GetArrayElType() = TypeInfo(TValue)); end;

Before you go messing around with your SSL setup, you should VERIFY whether OpenSSL is even the culprit to begin with. Use a dependancy walking tool to check your EXE and all DLLs your app uses, see which module is actually importing ConvertThreadToFiberEx().

That's why I said - "It is your responsibility for tracking your objects and making sure they stick around between (re-)connects." That is one option. But client IP alone is not unique enough if multiple clients are coming from the same network.

No, sorry. The simplest approach is to just use TIdContext.Data, it is an opaque Pointer, you can assign whatever you want to it. Deriving from TIdServerContext offers more flexibility, as you can define any extra fields, properties, and methods that you want.

TIdTCPServer handles that just fine. It is your responsibility for tracking your objects and making sure they stick around between (re-)connects. But as for the actual association, TIdTCPServer provides two options: TIdContext has a public Data property, which you can use to associate a client with your custom data. You can derive a custom class from TIdServerContext, add whatever you want to it, and then assign that class type to the TIdTCPServer.ContextClass property before activating the server. Then, in the server's events, you can type-cast the provided TIdContext object to your custom class. When the client disconnects from the server an the owning thread is stopped. Most likely, yes. When a client connects, you can issue it a token. If the client reconnects, it can ask to reuse that same token. When the client is finished with the token, the server can invalidate it. Unless you have some other way to associate each client with a given resource, such as with a unique login userid, etc. The server will tell you in the OnDisconnect event. That is not necessary. The server is already running the client interaction in its own thread. If a client disconnects for any reason, the OnDisconnect event will be triggered, before the context is destroyed.

Why are you putting your Java class in an Embarcadero package? You should be creating your own package. How does your C++ project refer to your MySimpleClass.jar file? Did you use the Project Manager, or a manual classes.dex file? Have you considered creating a JNI Bridge to your class, instead of manually using JNI methods directly? Using a Custom Set of Java Libraries In Your RAD Studio Android Apps Creating and Deploying a classes.dex File Manually Adding A Java Library to Your Application Using the Project Manager Something else to keep in mind (not sure if this applies here): https://stackoverflow.com/a/20843365/65863

Can you be more specific? What exactly was disrupted? It makes sense that lack of OpenSSL DLLs would cause errors for clients that try to connect using TLS, but that is handled on a per-client basis, it should have disrupted the entire server as a whole. Once a TLS handshake begins, if TLS fails for any reason, you can't continue communicating with that failed client, the connection must be dropped. OpenSSL MIGHT be able to send an alert to the client, depending on what stage of TLS the error occurs at, but that is the extent that can be sent. You certainly cannot send the original exception back to the client. On the other hand, if an exception happens that is not related to TLS, then you can certainly catch it and send whatever you want back to the client, but that depends on the design of your application protocol. As long as you do that in a thread-safe manner, it shouldn't affect other clients.

Does that mean you are using the "current" Indy version that shipped with 11.3, or you are using the "current" version from Indy's GitHub? 11.3 was released 2 years ago.

Are you sure that is the real error? ParseJSONValue() does indeed have an overload which takes in a string. However, the TRESTRequestParameter.Value property is also a string, but ParseJSONValue() returns a TJSONValue object pointer. So you would need to either just get rid of the TJSONObject entirely: var aParam: TRESTRequestParameter; begin aParam := RestReq.Params.AddItem(); //don't care about setting a name for it aParam.Value := '{"payment_method":["credit-card","open-banking"]}'; ...... RestClient.Execute(); end; Or, convert it to a string: var aParam: TRESTRequestParameter; aObj: TJSONObject; begin aObj := TJSONObject.ParseJSONObject('{"payment_method":["credit-card","open-banking"]}') as TJSONObject; try aParam := RestReq.Params.AddItem(); //don't care about setting a name for it aParam.Value := aObj.ToJson; finally aObj.Free; end; ...... RestClient.Execute(); end;

Just because modern OpenSSL is not directly in Indy itself yet does not mean there are no options for it at all. For example: https://github.com/JPeterMugaas/TaurusTLS Did you see this? https://www.indyproject.org/2024/10/20/sasl-oauth-support-finally-added-to-master/

Yup, that's the boat I'm in now...

HA! Yeah, like that'll never happen (famous last words!). My current company uses Java/Typescript, C#, and Visual C++. They had like 1 Delphi side project many years ago, but it hasn't been touched since and I think it got replaced with something else. My previous company, on the other hand, used C++Builder pretty extensively, and my boss at the time was well-aware of my TeamB activities.

And that is.... what, exactly? It is not a good idea to just post a link to some random code and expect people to understand what you are doing.

The CustomHeaders property is an indexed property. It is used only to read/write individual headers by name. You are seeing the methods of a single UnicodeString instance. There is no option to clear the whole list using the CustomHeaders property. However, you can use the CustHeaders property instead (not to be confused with the CustomHeaaders property!). It gives you access to the whole list, and it has a Clear() method: nhc->CustHeaders->Clear(); // NOT nhc->CustomHeaders->Clear(), // which does not exist....

At work, certainly. But if you mean my involvement in the Embarcadero community, then no. I keep those two worlds separate.

Agreed. My boss can't stop raving about it. AI this. AI that. Everyone needs to use AI. The last few weekly 1x1s I've had, lets check your AI usage this week. It's getting rediculous.

Do you mean SafeLoadLibrary()?

LoadLibrary() is a Win32 API function, so it is only available on Windows, you CAN'T use it on other platforms. That being said, other platforms have their own equivalents. For example, 'Nix-based platforms (which includes OSX, iOS, Linux, and Android) have dlopen() instead. You are going to have to use the appropriate API for each platform you want to support.

And if you run into problems with that, see: