Remy Lebeau

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?

Are you the one putting the data on the clipboard to begin with? If so, then why not store the required file size explicitly? If you can't put it in the MIME data itself, you can store it as a second format alongside the MIME data. The clipboard can hold more than one data item at a time.

In case anyone is not already aware of this https://quality.embarcadero.com is now in a permanent read-only mode. A new system is being implemented, but has not been opened to the public yet. So, if you do have a legit bug/feature to report, feel free to post it in a public forum, or write to Embarcadero directly, and someone who has internal access to the new system can open tickets for you until the new system is ready for public use.

No. Using a share path only works on the local LAN network, and only if the file is exposed by the server to the LAN via a UNC share to begin with. If you want to copy a file over the Internet, you need to setup a suitable TCP server for that, such as an HTTP or FTP server.

That is a completely different issue. I don't see how that applies here.

That is not correct. Technically, the path component is allowed to be empty in any url, per RFC 3986 sections 3 and 3.3: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> RFC 2616 section 3.2.2 tried to restrict an HTTP url to require a non-empty absolute path if the query component is present: http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] But, RFC 2616 section 5.1.2 does allow the path in an HTTP url to be empty: RFC 7230 sections 2.7.1 and 2.7.2 loosen the restriction to allow the path in HTTP and HTTPS urls to be empty: http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Why would you an inefficient "Pos" check instead of using something like StartsText() instead? Or simply: "if (FPath = '') or (FPath[1] <> '/')" ?

Not without more information about what a "dauha attendance machine" is, and what its HTTP API actually looks like.

Clearly a nil pointer is being accessed, but there is not enough information to diagnose where exactly. Is it happening in your own code (the most obviously candidate is the ALVideoPlayerSurface1.VideoPlayer property being nil), or is it happening inside the Alcinoe library?

Sorry, that is not how HDPI works.