Remy Lebeau

Because it dictates which offset is used for calculating UTC from the PC's location. For example, a PC clock set to 12:00PM PST is going to report a different UTC time than if its clock were set to 12:00PM EST instead.

Yes, it is the UTC time of the local PC clock. Internally, it converts the result to local time, yes. But the NTP protocol itself (RFC 5905) reports time in UTC. Technically, the DAYTIME protocol (RFC 867) does not define any particular string format or locale for the output, so it could be anything the server wants, in any format, any timezone, etc. The TIME protocol (RFC 868) is expressed in UTC. Indy's TIdTime and TIdTimeUDP implement this protocol. They both convert the result to local time when queried as a TDateTime, same as TIdSNTP does, however you can also get the original UTC response in UInt32 format instead via the DateTimeCard property. Per https://tf.nist.gov/tf-cgi/servers.cgi, NIST suggests that all clients of NIST servers update to using the NTP protocol, which is what TIdSNTP implements, which you have already ruled out as a solution. TIdSNTP does not expose access to the UTC response.

TDialogService.MessageDialog() is asynchronous on Android, per the documentation, so the dialog won't appear until after SpeedButton5Click() has exited. As such, your code is trying to use the Reply variable before it has actually been assigned a value, which is why StartLogin10() is not being called. Android simply does not support modal dialogs, and so the RTL does not implement any synchronous dialogs on Android. See Using FireMonkey Modal Dialog Boxes, TCommonCustomForm.ShowModal(), and IFMXWindowService.CanShowModal() for more details. You need to move the call to StartLogin10() inside the MessageDialog() callback, eg: procedure TFrmLogin.SpeedButton5Click(Sender: TObject); begin if (lst2.Items.Count <> 0) and (lst2.ItemIndex <> -1) then begin TDialogService.MessageDialog('you are gonna edit something ', TMsgDlgType.mtInformation, [TMsgDlgBtn.mbYes], TMsgDlgBtn.mbYes,0, procedure(const AResult: TModalResult) begin if AResult = mrYes then StartLogin10 else ShowMessage('you have cancel the operation'); end ); end else ShowMessage('chose something from the list'); end;

No, that project has been dead for a long time. No. The only thing I can find is this: https://sourceforge.net/projects/indysoap/

There is no way to answer that without seeing your actual code, and a trace of the underlying HTTP traffic. But the fact that your whole app hangs suggests that either you are not using threading correctly, or your main UI thread is waiting on the HTTP thread when it shouldn't be.

Then you should be fine using the latest Indy with OpenSSL 1.0.2, as it supports TLS 1.2

It is not enough to just use the .hpp files, you have to link to the RTL library as well. You are not finding SYSTEM.CLASSES.OBJ because is not actually a standalone file that exists anywhere. System.Classes is a unit that exists inside of the RTL. So make sure you are linking against rtl.dcp, IIRC. The easiest way to go is to just start with a newly created VCL-enabled console project and then add the translated C++ code into it as needed.

GetSystemTime() is dependent on the local computer's clock/timezone being configured properly, which Ian doesn't want to rely on.

EIdTLSClientTLSHandShakeFailed is raised when another exception is caught internally during the SSL/TLS handshake process. So the EIdTLSClientTLSHandShakeFailed.InnerException should not be nil. What are the values of the ClassName and Message of that InnerException?

.hpp files are auto-generated by the Delphi compiler when run with the -JL or -JPHNE switch. See Creating C++ Files from DCC32

A pool would make sense only if you want to limit the number of threads that are run simultaneously. Say, you have all 40 tasks, but you only want 10 to run at a time. So you create 40 tasks and put them in a queue, and then start the first 10 tasks, and each time a task finishes then it starts the next task in the queue until the queue is empty. If you are doing the wait in the main UI thread, MsgWaitForMultipleObjects() would be a better choice, so that you can detect when the message queue has pending messages waiting to be processed. But really, you shouldn't be waiting on the tasks at all, you should let them notify you when they are finished, like @Fr0sT.Brutal described. Except maybe at app shutdown, when you need to terminate and wait on any tasks that haven't finished yet.

A straight C++ translation of the Hash_Console demo would look something like this: /****************************************************************************** The DEC team (see file NOTICE.txt) licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. A copy of this licence is found in the root directory of this project in the file LICENCE.txt or alternatively at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ******************************************************************************/ /// <summary> /// Most simple demonstration of DEC hash routines /// </summary> #include <vcl.h> #pragma hdrstop #include <System.SysUtils.hpp> #include <DECFormat.hpp> #include <DECHash.hpp> #include <iostream> #include <limits> int main() { THash_RipeMD160* Hash = new THash_RipeMD160; try { try { // Calculate a hash value in accordance to the original author's test data // http://homes.esat.kuleuven.be/~bosselae/ripemd160.html RawByteString s = "message digest"; std::cout << "RipeMD160 digest (hash value) of " << s.c_str() << " is \n" << Hash->CalcString(s, __classid(TFormat_HEX)).c_str() << std::endl; std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n'); THash_Whirlpool1* W = new THash_Whirlpool1; s = "The quick brown fox jumps over the lazy dog"; std::cout << "RipeMD160 digest (hash value) of " << s.c_str() << " is \n" << W->CalcString(s, __classid(TFormat_HEX)).c_str() << std::endl; delete W; std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n'); } catch(const Exception &E) { std::wcout << const_cast<Exception&>(E).ClassName().c_str() << _D(": ") << E.Message.c_str(); } } __finally { delete Hash; } }

Set the Selection property to a TGridRect containing all -1's. var gr: TGridRect; gr.Left := -1; gr.Right := -1; gr.Top := -1; gr.Bottom := -1; DrawGrid.Selection := gr;

Yes, it has done so for a very long time, since at least Delphi 5, probably even since TThread was first introduced. But just because it CAN doesn't mean it SHOULD. And like I have said, many people have had problems related to this "feature" over the years, which is why I never recommend relying on it.

That implies that Play() is acting synchronously, not exiting until the audio is finished, thus blocking the main thread from rendering UI updates. Is that actually the case? It should be running asynchronously instead.