Remy Lebeau

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.

Thanks, good catch. I'll fix it shortly and get it merged in.

The cleanup scripts don't INSTALL anything. They REMOVE the pre-installed copy of Indy they ships with the IDE. Nothing more. You have to then compile Indy yourself. By default, the projects are setup for Win32 only. You would have to configure the desired platforms as needed.

Hmm, it worked fine for me when I tested it on my system. I don't have 12.1 installed yet. Feel free to submit a Pull Request or email with any changes needed.

I already fixed that issue a month ago, and I told you that at the time:

RAND_screen was deprecated in OpenSSL 1.1.0 and hidden behind compatibility macros. So it is possible that it doesn't even exist in your copy of the OpenSSL libs.

Neither of those types have the same size as string32. string32, aka string[32], is 33 bytes (1 byte length + 32 AnsiChars). This has not changed over the years. ShortString, aka string[255], is 256 bytes (1 byte length + 255 AnsiChars). This has not changed over the years. array[1..32] of Char is 32 bytes in D5, but 64 bytes in XE. There is no length byte in the array, and Char itself is different. Prior to 2009, it was AnsiChar. Post 2009, it is WideChar.

That's not going to happen anytime soon, if ever. You will have to write your own function if you want that kind of functionality. MIME is complicated. No, the Dest stream only contains the body content (that is why the method is called ReadBody()). The Decoder has a Headers property, which is populated by the call to the ReadHeaders() method. The headers are stored as a TStrings in "name=value" format. You can use Indy's ExtractHeaderSubItem() function to get the "name" and "filename" attribute values from the "Content-Disposition" header.

TIdHTTPServer does not currently support extracting values from a "multipart/form-data" request (see https://github.com/IndySockets/Indy/issues/138). You have to parse the raw MIME data in the PostStream yourself. You can use Indy's TIdMessageDecoderMIME class to help you with that. See https://en.delphipraxis.net/topic/10918-multipartform-data-vs-x-www-form-urlencoded-indy-http-server/ for an example.

Agreed. XML carries its own encoding information, which any compliant parser must handle. So always pass raw bytes into an XML parser and let it work out the encoding, don't decode the bytes yourself.

Is Raymond Chen's word not proof enough for you?

THAT'S an important piece of information that was missing. Python4Delphi's MainModule is a function that returns a custom Variant holding a reference to Python's __main__ object. A custom class named TPythonVariantType derived from Delphi's TInvokeableVariantType is used to allow such Variants to access properties and methods of the Python objects they hold. So, in your example, when you call MainModule.ClickElement_ByXPATH, the Delphi compiler emits code to pass the MainModule Variant to Python4Delphi's implementation of TPythonVariantType.DoProcedure() or TPythonVariantType.DoFunction() (depending on whether a return value is used or not) to invoke the "ClickElement_ByXPATH" function by name at runtime. So, to do what you are asking for, you could invoke TPythonVariantType.DoProcedure() manually, eg (UNTESTED!): uses ..., Variants, VarPyth; var custType: TCustomVariantType; v: Variant; begin // MainModule.ClickElement_ByXPATH(); if FindCustomVariantType(VarPython, custType) then begin v := MainModule; custType.DoProcedure(TVarData(v), 'ClickElement_ByXPATH', nil); end; end;

How are you calling Python functions from Delphi code to begin with?

Are you wanting to call a Python function dynamically from Delphi code? Or call a Delphi function dynamically from Python code? Its not clear what you are looking for. Can you provide an example?