Remy Lebeau

DNS lookups and connect attempts are two different things. I don't think you can do non-blocking DNS lookups using the standard hostbyname()/getaddrinfo() APIs that most people's socket code uses. You would have to use platform-specific APIs (ie, like DnsQueryEx() on Windows), or send manual DNS queries over non-blocking sockets. A connect() timeout can be implemented by just using a non-blocking socket and close() the socket after the timeout elapses. If it uses a thread internally, that is just an implementation detail of the OS, but that shouldn't block the app from being able to move on.

Why TIcsIpStrmLog and not TSslWSocket directly? Are you saying that ICS does not support connect timeouts on TCP sockets at all? Or just that the TIcsIpStrmLog component specifically does not support this? In general, there are ways to implement a connect timeout on a TCP socket - namely: by using a non-blocking socket with select() or (e)poll() for the timeout. by aborting the socket from another thread. I would be surprised if ICS does not use the first one.

I have never seen a "default" key value be named "(Standard)". It's always been named "(Default)" on every system I have ever used, eg:

You should use different ports for HTTP and HTTPS. While it is technically possible to handle both HTTP and HTTPS on a single port, it requires extra coding to peek the raw TCP data before the HTTP server processes it. It is usually not worth the effort unless you are dealing with network restrictions.

What version are you using? What service url are you using? Things have changed in recent years.

Raymond Chen's blog article on Manipulating the positions of desktop icons includes code "to enumerate all the desktop icons and print their names and locations."

Why? You can reuse TIdHTTP for multiple requests. Are you creating it in the thread constructor? Or inside of the thread Execute()? They run in different thread contexts

It also has the added benefit that it has an optional Delay parameter, if you need a longer sleep between steps, similar to a timer.

Where do you see that documented? According to this documentation, the return type of the LogicalAnd and LocicalOr operators is simply specified as "resultType", nothing says it is required to be Boolean, so it can be whatever type the implementation wants.

By definition, a TryXXX() function does not raise an exception into user code. TryISO8601ToDate() is no different. Now, it may be that it generates an internal exception on failure, but that is merely an implementation detail, such an exception will certainly not escape into user code. If you don't want to see the exception inside the debugger, you can configure it to ignore EDateTimeException and EConvertError exceptions. Regarding that exception, TryISO8601ToDate() is implemented backwards than other TryXXX() functions. In most RTL functions, DoX() calls TryDoX() to do the actual work, and then raises an exception if TryDoX() fails. But TryISO8601ToDate() is different - it calls ISO8601ToDate() to do the actual work, and then suppresses any exception that ISO8601ToDate() raises. What they SHOULD have done instead is move ISO8601ToDate()'s logic into TryISO8601ToDate(), and then make ISO8601ToDate() raise if TryISO8601ToDate() fails. But, it turns out that ISO8601ToDate() raises a different exception message depending on why it fails. Perhaps they could have created a new internal function do perform the actual work and have it report the failure reason to the caller, then TryISO8601ToDate() could ignore the reason, and ISO8601ToDate() could raise an exception based on the reason. Oh well...

Indy doesn't have a real CI system. But yes, generation of the cmd script could be automated in some way using information that Indy already has (there is already some automation in place to generate the Package projects themselves). To reduce duplication, I could auto-generate a separate cmd script that just deletes the known Indy files in the current directory, and then have Clean_IDE.cmd call that script where needed. Those files are not part of Indy itself, they are part of an internal wrapper on top of Indy which Embarcadero uses to separate its use of Indy from other Embarcadero code. But, there are other differences Embarcadero does make to Indy itself - most notably, the Packages are changed to use LIBSUFFIX, etc.

That is not the correct way to handle this. You need to accept non-TLS connections on the HTTP port, and for any request that is received on that port, send an HTTP redirect response specifying the desired HTTPS port. That way, the client can then retry the same HTTP request on the HTTPS port using TLS. You don't need to handle that manually in TIdHTTPServer. Use the OnQuerySSLPort event instead, and let TIdHTTPServer handle the PassThrough for you. Any port that OnQuerySSLPort returns VUseSSL=True for will use PassThrough=False, and vice versa. ☝️☝️☝️ This is the way!

There is no reason to assign a value to DefaultPort if you are creating only 1 Binding and setting its Port, thus overwriting what the DefaultPort already assigned. On the other hand, there is no point in assigning the Binding's Port if you are assigning it the same value as DefaultPort. The whole point of DefaultPort is it is the initial Port that is assigned by Add(). Such weird behavior is typically a classic symptom of "Undefined Behavior" being invoked elsewhere in your code, and this code is likely just an unexpecting victim of it. For instance, if random memory were being corrupted, and then this code tries to access that memory. Why are you using a TStringStream for raw file data? If you really need to load the file data into a String (ie, the file is textual), then you could simply use ContentText instead of ContentStream, no need to use a TStream. As I mentioned earlier in this thread, if you catch exception, you should RE-RAISE any Indy exceptions that are caught, eg: except on E: Exception do begin Log(req.URI + ' : ' + req.Document + sLineBreak + E.ClassName + ' : ' + E.Message); if E is EIdException then raise; // <-- ADD THIS end;

As Anders mentioned, you likely don't have permissions to retrieve all processes for other users. That being said, you might consider trying EnumProcesses() and see if it returns more entries. That being said, there are quite a number of issues with the code you have shown: You are leaking the THandle returned by CreateToolhelp32Snapshot(). GetName() is over-complicated. The data.szExeFile value is guaranteed to be null-terminated, so your loop is completely unnecessary (not to mention your use of a Byte for the loop counter means you might potentially truncate long filenames). You can simply assign the data.szExeFile value as-is to the Result without concatenating Char-by-Char (also, your comparison of a single Char to a blank string makes no sense at all). For that matter, you could just get rid of GetName() altogether and simply add data.szExeName as-is to your TStrings. You are not protecting your code from unexpected exceptions, which will cause several leaks if something goes wrong. There are several places in your code where you should be using try..finally blocks to free/release resources properly. You don't need to use the global Form1 variable inside of TForm1's own methods. Use each method's Self pointer instead.

CM_TEXTCHANGED is a VCL message, it doesn't exist in FMX. When the TLabel.Text property is changed in FMX, there is no window message issued back to the TLabel, but there are virtual methods called instead, such as DoChanged() and DoTextChanged(). It should also be mentioned that the Text setter already calls Repaint() after calling the virtual methods.