Remy Lebeau

True, though there is the Declarations and Statements (Delphi) documentation, which does state all declarations are terminated by a semicolon.

I asked Embarcadero about the error and they said this: So, "installing" the 12.2 Patch 1 from GetIt merely downloaded the installer, but did you actually run it? The build version should have been updated from 29.0.53571.9782 -> 29.0.53982.0329 if the patch was actually installed. They also said: The TParallelArray class constructor was added in the original 12.2 release, but was removed in the 12.2 inline patch. So, if your package is referring to the constructor after installing 12.3 then it was compiled with the un-patched build of 12.2.

CryptRetrieveTimeStamp simply does not exist on XP. If you have source code for FastReport then you will have to modify and recompile it to not use CryptRetrieveTimeStamp on XP. Or else contact the FastReport author for help.

Did you have all of the patches for 12.2 installed before you upgraded to 12.3? Patch 1 in particular dealt with package compatibility issues, so if you didn't have it installed then perhaps your packages are not compatible with 12.3.

No. 12.3 is a minor point update in the 12.x series, so you have to remove 12.2 when installing 12.3. Only different major versions can coexist.

No. A single IOHandler object (of any type, SSL or otherwise) cannot be shared by multiple active connections at the same time. Each connection needs its own unique (SSL)IOHandler object while it is connected to a peer. Yes. Each (SSL)IOHandler is associated with a single data transport (such as a socket), and a single set of buffers for incoming and outgoing data.

I didn't say Delphi doesn't support PNG. I said TImageList doesn't support PNG. Internally, TImageList is based on the Win32 IMAGELIST control, which supports only BMP and ICO images. They can't "fix this" as it is a Win32 limitation. They worked around it (amongst other reasons) by creating TImageCollection and TVirtualImageList to replace the old TImageList: Supporting high-DPI images with the Image Collection and Virtual ImageList components Probably, yes.

Standard TImageList does not support PNGs only BMPs. Try TImageCollection+TVirtualImageList instead. Or, there's a 3rd party TPngImageList floating around somewhere.

Because those are the only 2 extensions that the VCL registers for TWICImage. But the WIC library supports so much more. Windows Imaging Component Native WIC Codecs Most likely, yes. WIC can be extended with custom codecs. The VCL does not provide a way to enumerate file extensions that WIC supports. But WIC itself does via its IWICImagingFactory interface, which you can access by the TWICImage::ImagingFactory property. Use IWICImagingFactory::CreateComponentEnumerator() to enumerate its available codecs, query each one for IWICBitmapCodecInfo, and then use IWICBitmapCodecInfo::GetFileExtensions().

As stated earlier, a only handful of formats are supported by default. If you were not already including those units explicitly, maybe they were being included implicitly somewhere else. Or maybe something else in your program is providing the necessary support. Then something else in your program is providing support for WEBP, because that is not a format that the VCL supports natively.

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;