Remy Lebeau

Sounds like an issue that needs to be reported to Embarcadero.

No, see: http://docwiki.embarcadero.com/RADStudio/en/Exceptions_(Delphi)#Try...finally_Statements

I can't answer that. And? Did you try using a newer version of OpenSSL? 1.0.2q is not the latest (I'm guessing you are using the libraries from Indy's GitHub repo?). The last version in the 1.0.2 series was 1.0.2u. I don't have Android binaries for that version, but I'm sure you can find them if you search around. For supporting the OpenSSL 1.1.x series, there is this SSLIOHandler instead, but I don't know if it works on Android or not. Do you have libssl.so in the same folder? Are they from the same OpenSSL version? Are you calling Indy's IdOpenSSLSetLibPath() function at program startup?

Modern Android versions simply don't support OpenSSL anymore. They use BoringSSL instead, which Indy does not support. And on some (not all) Android devices, BoringSSL gets used even if the app tries to use OpenSSL dynamically. So, unless you statically build OpenSSL directly into your app binary, using OpenSSL on Android is a hit-or-miss endeavour. What does Indy's WhichFailedToLoad() function report when the error occurs? Also, does Indy's OpenSSLVersion() function report anything?

Not according to the documentation those links point to, they don’t. You can install a thread-local hook from SetWindowsHookEx() or SetWinEventHook() before calling TaskDialogIndirect()/TTaskDialog.Execute(), to intercept the dialog’s HWND when it is actually created, and then you can do whatever you want to it.

It is for both: https://devblogs.microsoft.com/oldnewthing/20031229-00/?p=41283 Unlike VCL, FMX does not allow you to customize the creation of a Form’s HWND, so there is no option to remove the WS_EX_APPWINDOW style up front. Not without modifying FMX’s source code, as you have discovered. Is there a Unit1 already present in the source folder, if not in the Project? When creating a new unit, the IDE looks at existing units in the folder and chooses the highest unused sequential number. The best way to avoid creating the taskbar button at all is to not create any top-level HWNDs that have the WS_EX_APPWINDOW style. Something FMX tries to prevent you from doing.

https://stackoverflow.com/questions/16768986/how-to-hide-firemonkey-application-button-from-taskbar-xe4 https://stackoverflow.com/questions/53765725/hide-taskbar-button-in-fmx-on-windows

Starting a new elevated process can be done using the Win32 API ShellExecute/Ex() with the "runas" verb. Instantiating an elevated COM object can be done using the COM Elevation Moniker.

Would one of these work for you (not sure whether UtcOffset returns positive or negative for, say, UTC-08:00)? Result := TTimeZone.Local.UtcOffset.TotalMinutes / 60 / 24; or: Result := -1 * (TTimeZone.Local.UtcOffset.TotalMinutes / 60 / 24); This would avoid having to query the system clock at all. I'm thinking of updating IdGlobal.OffsetFromUTC() to use TTimeZone internally when available, in which case TimeZoneBias() under Delphi UNIX can just be: Result := -OffsetFromUTC; Like it is on all other platforms.

That would require moving the routine into a separate process or COM object that can then run elevated.

I assume, then, that gettimeofday() is failing? That might be related to this: https://github.com/IndySockets/Indy/issues/245 Thanks. I'll look into incorporating TTimeZone into Indy. There are quite a number of code fragments that can make use of it. What issue is that? Is it an Indy issue, or just a Delphi issue?

But WHERE is it hanging exactly? You need to determine that. Is it on the actual transmission of the request packet? On the receiving of the response packet? On the setting of the PC clock? Your code is calling only 1 method (SyncTime), but that method does multiple things internally, so there are multiple points of failure. Have you tried to use a packet sniffer, like Wireshark, to make sure the SNTP request is actually being sent, and an SNTP response is being received? That is because SNTP runs over UDP, so there is no connection, like you are thinking of. A UDP socket can be "connected" to a remote peer by assigning the peer's IP address statically to the UDP socket, thus sends/receives via that socket will interact only with that particular IP. But that is optional. Your code is not calling the TIdSNTP.Connect() method to establish such a static association, which is why you are not seeing the OnConnected/OnDisconnected events being fired. By default, TIdSNTP will simply write a datagram to the network and then wait for a responding datagram to come back from any peer to TIdSNTP's sending port, which is usually fine in most cases.

That means Indy's IdGlobal.OffsetFromUTC() and/or IdGlobalProtocols.TimeZoneBias() function is returning a time zone offset of 0.0. So, either the function(s) are failing to query the OS for the correct time zone, or the time zone is actually being reported as UTC. You are going to have to debug into Indy's code to see which is actually the case. No. The local time zone is always queried dynamically. It just happens to be coming back as offset 0 in your situation. I can't answer that without more details about what exactly is failing.

That is wrong. The PopupParent should be the AudioForm instead, since it is the one invoking the print dialog. There is only 1 good reason to ever do that - if you want the AudioForm to be a top-level window (acting as a sibling of the MainForm, so either Form could appear on top of the other at any time) with its own button on the Taskbar. Otherwise, without that code, the AudioForm would by default be owned by the TApplication window (when Application.ShowMainFormOnTaskbar=false) or the MainForm window (when Application.ShowMainFormOnTaskbar=true), and thus would not have a Taskbar button, and would always appear on top of its owner, never underneath it.

No, it is not, as the code in question is not creating any new JSON objects, only reading them. The framework will do all of the necessary creations for you while parsing the JSON string. It is not necessary in this example at all. If you were creating a new JSON document, THEN you would have to create new objects as needed. Only the root object returned by ParseJSONValue() needs to be freed explicitly. The rest of the objects in the document are owned by the root object and will be freed automatically when the root object is freed.