Remy Lebeau

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.

Then there is no point in enabling the CheckBox on the DateTimePicker itself.

TThread.Synchronize() is not limited to just GUI work, though that is what it is commonly used for. It just serializes threads to run code though the main UI thread, nothing more. TThread.ForceQueue() is meant to be used in the main UI thread only, worker threads should use TThread.Queue() (or TThread.Synchronize()) instead. TThread.Synchronize() and TThread.Queue() bypass the internal queue when they are called in the main UI thread. TThread.ForceQueue() was added so the main UI thread can queue things up, too. Or, simply wrap the variable behind a thread-synchronization object, such as TCriticalSection, TEvent, TConditionalVariableCS, TMREWSync, TInterlock, etc. Many different ways to protect a variable from concurrent access across multiple threads. Not really. Android runs on top of Linux, so its base threading is pretty similar to other platforms. However, there are restrictions on what can and cannot be executed on the UI thread, for instance, but that is artificially enforced by Android's implementation of Java, not Linux itself.

A DateTimePicker does not have a concept of a NULL date/time. That is why it has an optional checkbox instead. If you need the date/time value to be optional, then enable the check box, and if checked then use the date/time otherwise ignore it. You can't assign a NULL date/time value, so just uncheck the box and set a default value if needed.

Given that your images are large, and not even bitmaps to begin with, I would suggest an alternative approach - get rid of the TImageList altogether. Instead, create an array/TList of TJPGImage objects, and then owner-draw them onto your ListView/ListBox items as needed.

The System.AnsiStrings.AnsiCompareStr() function uses the Win32 CompareStringA() function on Windows (the System.SysUtils.AnsiCompareStr() function uses CompareStringW() instead). But, CompareStringA() assumes the input strings are in the ANSI encoding of the specified locale. The MSDN documentation says:

I reported the issue to Embarcadero privately and they are looking into it.

Interesting. I just tested that in 12.0 Patch 1 and sure enough the springing works. However, removing the 'else' does prevent the dragging from going smaller than the MinWidth to begin with.

As I said, I confirmed the bug does not exist in 10.3, but does exist in 12.0, so it's possible that it does not exist in 11.3 either. I don't have that version to check with. If you look in your IDE's copy of the Vcl.ComCtrls.pas source file, do you see the code I showed earlier?

Tested, works fine (also, you don't need to use "Self."). You can also use an inline variable to simplify your example further: procedure TAncestor.DoSomething; begin var md := ProcX; if TMethod(md).Code <> @TAncestor.ProcX then // Overridden. else // Not overridden. end; Do note that in the original TStream code, using @TStream.Seek like above won't work since Seek() is overloaded, so the compiler wouldn't know which overload to compare with. Hence the original code's use of a typed variable to resolve the ambiguity, eg: procedure TAncestor.DoSomething; type TProcX = procedure of object; var Impl, Base: TProcX; ClassTAncestor: TClass; begin ClassTAncestor := TAncestor; Impl := ProcX; Base := TAncestor(@ClassTAncestor).ProcX; if TMethod(Impl).Code <> TMethod(Base).Code then // Overridden. else // Not overridden. end; This works for both overloaded and non-overloaded methods. I have reported this enhancement to Embarcadero now: https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-548 As for the invalid cast errors, they are probably the compiler trying to CALL the method first, and then cast the (lack of a) return value. You have to do the comparisons through the TMethod record, and that requires a variable which you can type-cast.

I have now merged in your changes. For consistency, I re-arranged the order of the new directories that you had added.

IIRC, activation issues are now handled by SALES not SUPPORT.

https://blogs.embarcadero.com/the-new-quality-portal-is-live-here-are-the-details/

Also, Embarcadero's own forums (which still had nothing to do with Licensing) were shut down several years ago.