Remy Lebeau

It is not. That is what you will have to do.

SetEnvironmentVariable() updates the environment of the calling process only, changes are not persisted when the process exits. You don't need to update the PATH to handle that. Use SetDllDirectory() or AddDllDirectory() instead.

https://en.delphipraxis.net/topic/2769-indy-openssl-111-tls-13/ At this time, it has not been merged yet, though. Still pending review...

I don't use ICS, but that would imply that THttpCli uses a non-blocking socket that relies on window messages to progress its state. In which case, yes, the THttpCli would need to be created in the same thread context that the message window is created in, ie created in the thread's Execute method or Run event, not in its constructor. Another argument in favor of using Indy's socket components, like TIdHTTP, is that they use only blocking sockets and no window messages, so they can be created and used across thread boundaries.

That kind of "check for empty buffer" logic makes sense in a UI timer, to prevent blockage of the UI. It makes less sense to use that kind of logic in a worker thread, as demonstrated in that same post.

Yes, and you need to make sure that is enabled for not just the EXE but also for your own Packages, too. Yes, but only if your packages actually use functionality from the RTL package so its linkage is not optimized out. It would be really useful if you could post an actual code example that is not working for you.

It is not enough to just enable "runtime packages" in the main application. Package1 and Package2 must also be compiled with "runtime packages" enabled, and the "common unit" must be in a 3rd runtime package that they both require. Yes, the RTL package is sufficient, but you have to make sure Package1 and Package2 are linking to it dynamically (ie, you need to ship "rtl240.bpl" alongside your own BPLs) and not statically, otherwise they end up using separate copies of the RTL.

I was thinking the same thing. Yes, TIdThread is part of Indy. So, why wouldn't you want to use Indy's TIdHTTP component if you are using Indy for other things?

The point was, if you use the plain vanilla TCP client/server components, then you have to design your own protocol on top of them, and implement both sides of that protocol. If you use a standard protocol, like FTP or HTTP, then you don't need to implement both sides (unless you really need to customize both sides), you can use pre-existing implementations. And HTTP has benefits over FTP. "check buffer is empty" is not a good way to approach this task in the first place.

And I do appreciate that work, and I will review it when I have time to do so (I wasn't able to get to it this past weekend, like I had hoped to).

Actually, Embarcadero has slowly been cutting its dependencies on Indy over the past several releases. Eventually, I'd like to see Indy moved to GetIt as an optional install, like most other 3rd party components. But because Indy doesn't have a traditional install process (mainly for C++ support), that has been difficult to prepare.

Sort of, but mostly no. At this time, there are no plans to move away from the current model of 1-thread-per-connection w/ blocking I/O, since Indy is multi-platform and that model is very portable. However, on Windows, Indy's IdWinsock2 unit does currently have declarations for the RIO functions, although it does not actually import the functions at runtime. But you can do that manually by calling WSAIoctl() directly (which Indy does expose access to). Also, I did check in some updates to Indy a few months ago to allow users to create asynchronous sockets using Indy's API, although Indy itself does not make use of asynchronous sockets. We tried once before (the SuperCore package) to add support for fibers and IOCP to Indy on Windows, but that was an epic failure, it just didn't work right and didn't fit well with the rest of Indy's architecture. Maybe in the future, we might consider making some new Windows-specific components that are just native IOCP/RIO without trying to shoe-horn IOCP/RIO into the rest of Indy. Who knows. If we ever did, that would likely be WAY down the line. Maybe Indy 12, 13, etc. We haven't even released Indy 11 yet, and that will just be a maintenance version, no real new features, just mostly code cleanup. No ETA on that.

No, I do not. But I'm sure you can find some online. For example, here is a basic intro to get you started: Windows 8 Registered I/O Networking Extensions

And the FreePascal/Lazarus forum: https://forum.lazarus.freepascal.org/index.php/topic,49585.0/topicseen.html

Or Registered I/O.

Local variables that are un-managed types are not auto-initialized. Object pointers are managed types only on ARC platforms (iOS and Android). Strings are always managed types, integers are never managed types. Only global variables and class members that are un-managed types get auto-initialized to zeros.

Being a class type, you really can't specify a specific TEncoding value as a default parameter value. So you have to either: Use an overload (that is what Delphi's RTL does): procedure Save(const AData: TStringList); overload; procedure Save(const AData: TStringList; const AEncoding: TEncoding); overload; ... procedure Save(const AData: TStringList); begin Save(AData, TEncoding.UTF8); end; procedure Save(const AData: TStringList; const AEncoding: TEncoding); begin AData.SaveToFile(FileName, AEncoding); end; Or else use nil for the default value: procedure Save(const AData: TStringList; AEncoding: TEncoding = nil); ... procedure Save(const AData: TStringList; AEncoding: TEncoding); begin if AEncoding = nil then AEncoding := TEncoding.UTF8; AData.SaveToFile(FileName, AEncoding); end;

What does that code have to do with TListBox/TListView? Their Sort() methods are quite different than TObjectList's Sort() method.

Can you be more specific? What exactly is not working for you? Please show the code you are having trouble with.

Note the ETag was also different between the two responses, which means different versions of the resource were being accessed, which would explain why they had different timestamps.

There is already work being done to add 1.1.x support. Not by me, codewise, but I'll review and merge it when its ready.

And this is why I HATE Generics! They cause more headaches than they solve.

@Jacek Laskowski I can't test this myself (no working IDE), but what about if the 'record' constraint is added to the Generic so the compiler knows that T is a value type? ToField<T: record> = class private fData : T; protected procedure SetFromVariant(const aValue : Variant); end; procedure ToField<T>.SetFromVariant(const aValue : Variant); begin fData := aValue; end;

I already told you how. Clicking on a hyperlink inside the HTML is supposed to fire the OnShouldStartLoadWithRequest and OnDidStartLoad events. If it is not, then you should file a bug report. I don't understand what you are describing, but that doesn't seem to match with your screenshot. Are you running your code in the IDE's debugger? If so, the messages will go to the debugger's output window, not to DebugView.

Clicking on a hyperlink starts a load request. You should be getting events for that. Lets starts with the obvious - did you actually ASSIGN a handler to that event? I'm confused. What are you trying to say exactly? Can you provide a ste-by-step example?