Remy Lebeau

Winsock error 10014 is WSAEFAULT. I don't know ICS's internals, but presumably fSender.ReceiveFrom() calls Winsock's recvfrom() function, whose documentation says: Your lFromLen variable is uninitialized, so your code is passing an indeterminate value to recvfrom() which exhibits undefined behavior. Sometimes the value is too small, sometimes it is not. You need to initialize your lFromLen variable to specify the size of your lFromSock variable before calling fSender.ReceiveFrom(). On a side note: you are treating lCount=0 as an error condition, but it is not. Unlike TCP, UDP messages can be 0 bytes in size. You should be calling WSAGetLastError() only if lCount is SOCKET_ERROR (-1).

Does the host application display any UI windows of its own before the DLL's VCL form is displayed? If not, then does GetStartupInfo() report that the 1st window shown should be maximized?

All of the major OAuth providers - Google, Microsoft, etc - should have full documentation about their workflows.

When I debug a service, I simply run the service normally in the SCM, and have its OnStart event pause execution until the debugger is attached.

Geoffrey's demo uses Indy's TIdSMTP component to send email with an OAuth2 token. Indy has a TIdHTTPServer component (or TIdSimpleServer if you don't need a full-blown HTTP server).

Windows has enough resources to run thousands of threads in parallel. 10 is nothing. So something else is likely causing the error. The Scheduler manages only threads that it creates. It can't manage threads created by TIdThreadComponent. But again, the Scheduler doesn't limit threads that are running, only threads that are idle. When the Scheduler needs a thread, it pulls one from the pool if available, otherwise it creates a new one. When a thread is finished, it is put in the pool if there is room for it, otherwise it is terminated.

I don't really understand what you're trying to do. But the Scheduler components are not intended to be used standalone, they are meant to be used with TIdTCPServer and derived components. That being said, the pool size only effects the number of threads that are sitting idle in the pool. Not the number of threads that are actively running.

Why are you connecting to localhost? What exact steps are you doing to reach this error? What API are you using to access Google?

DPKs for Delphi 7 are available in Indy's GitHub repo: https://github.com/IndySockets/Indy You have to compile the DPKs yourself to get BPLs, Indy does not provide pre-compiled DCUs/BPLs: https://github.com/IndySockets/Indy/wiki/Updating-Indy OpenSSL DLLs that are compatible with Indy are available in Indy's GitHub repo: https://github.com/IndySockets/OpenSSL-Binaries Indy 10 currently supports up to OpenSSL 1.0.2u (but support for 3.x is in the works).

Again, in what context, exactly? Indy recently got some new SASL components for OAuth authentication for SMTP/POP3/IMAP. There is no direct OAuth support for HTTP at this time, though. In general, you are responsible for implementing OAuth protocols yourself depending on your chosen OAuth provider. But once you have a login token, there are ways to use it with Indy. Can you provide more detail about your specific use-case?

If it is not already in one of the RTL's 'Androidapi.*.pas' units (did you try grepping for it?), then you'll have to import it manually using Java2Op or similar tool, or use a 3rd party unit that imports it (like this one). Also, this statement: StringToJString('com.embarcadero.EMail.fileprovider') should be this instead: StringToJString(JStringToString(TAndroidHelper.Context.getApplicationContext.getPackageName) + '.fileprovider')

Anyone who would have such info would be under an NDA not to discuss it until Embarcadero announced it publicly first.

Did you read the documentation yet? Writing Multithreaded Applications Simply get rid of the @ symbol, pass the method by name only. Synchronize(UpdateUI); // Update UI safely from the main thread

The non-static Synchronize() method has always been protected. That is perfectly fine when calling it from within the thread's Execute() or DoTerminate() methods. There are also static Synchronize() methods available which are public and can be called outside of a TThread object. This is not a VCL vs FMX issue, since TThread is common to both of them.

"Best" is subjective and opinionated. There's are plenty of mature options that have the features you are asking for. Why? See above about not using the native components

No. In what context, exactly?

I answered your same question on StackOverflow before seeing it posted here too: https://stackoverflow.com/a/79151906/65863 I see you actually posted this same question on 3 forums at the same time: Delphi-PRAXiS, StackOverflow, and Lazarus. It's generally considered rude to ask the same question on multiple forums at the same time. It gives people the impression that you are in a hurry and don't value any given forum, and you'll usually get similar answers, and you lessen the value of people duplicating their efforts. Pick a forum, give it some time to amswer (like a few days at least), and if you don't get a satisfactory answer then try another forum if needed.

I can reproduce the issue. Interestingly, if you don't use the TRttiContext and just assign the ColorProp directly to the TValue then TValue.ToString() works as expected: //Val := AColorProp.GetValue(ColorObj); Val := ColorObj.ColorProp; // Val.ToString now returns '4294303411' In both cases, the numeric value (inside the TValue.FAsULong field) is correct, but the RTTI for the value different - in the first case, the TValue.FTypeInfo belongs to TAlphaColor, but in the second case the TValue.FTypeInfo belongs to Cardinal instead! Both RTTIs have Kind=tkInteger and OrdType=otULong, so the numeric value is stored in TValue.FAsULong and TValue.ToString() formats as a UInt64. But, the TValue.AsUInt64 property getter behaves differently on the two RTTI types: function TValue.AsUInt64: UInt64; begin if not IsEmpty then begin if FTypeInfo = System.TypeInfo(Int64) then Exit(FAsSInt64) else if FTypeInfo = System.TypeInfo(UInt64) then Exit(FAsUInt64) else if FTypeInfo = System.TypeInfo(Cardinal) then Exit(FAsULong) // <-- SECOND CASE else if FTypeInfo^.Kind = tkInteger then Exit(AsInteger); // <-- FIRST CASE end; AsTypeInternal(Result, System.TypeInfo(UInt64)); end; function TValue.AsInteger: Integer; begin if not IsEmpty then begin if FTypeInfo = System.TypeInfo(Integer) then Exit(FAsSLong) else if FTypeInfo^.Kind = tkInteger then case GetTypeData(FTypeInfo)^.OrdType of otSByte: Exit(FAsSByte); otSWord: Exit(FAsSWord); otSLong: Exit(FAsSLong); else Exit(FAsULong); // <-- FIRST CASE end; end; AsTypeInternal(Result, System.TypeInfo(Integer)); end; In the first case, TValue.FTypeInfo does not belong to either UInt64 or Cardinal (it belongs to TAlphaColor), so the TValue.FAsULong field (whose unsigned value is 4294303411, hex $FFF5DEB3) first gets converted to a signed Integer, resulting in a negative value of -663885 (hex $FFF5DEB3), which is then converted up to a sign-extended UInt64, resulting in a large unsigned value of 18446744073708887731 (hex $FFFFFFFFFFF5DEB3). In the second case, the TValue.FTypeInfo belongs to Cardinal (an unsigned type), so the TValue.FAsUlong field (hex $FFF5DEB3) is converted as-is to a zero-extended UInt64, preserving the original value (hex $00000000FFF5DEB3).

Well, since TEdit is supposed to be a single-line edit control, it doesn't make sense to enable word-wrapping on it by default. Use TMemo instead if you need a multi-line edit control.

I don't see why. It's still clang, just a newer version with a higher language compliance. At this time, the newer clang compiler is available only for 64bit.

Umm, are you not aware that there is already a 32bit Clang compiler? (two, actually). You can switch to it by turning off the "Use 'classic' Borland compiler" option in the project settings. https://docwiki.embarcadero.com/RADStudio/en/Win32_Clang-enhanced_Compilers The difference between the 32bit Clang compiler and the newly released 64bit Clang compiler (besides bit-size, obviously) is that the 64bit compiler uses a newer version of clang. But, after it has matured a little bit, I'm sure they will update the 32bit compiler too, as 32bit development is still popular. But, at least you can get started using clang today.

Sorry, I had misread your earlier message.

StrToFloat() does not have an option to return a default value. You need to use TryStrToFloat() for that.

In 64bit, you can't mix inline assembly with Pascal code in the same function, but you can still write entire functions in just assembly and then call them from Pasal functions. You can't. At least, not in a Pascal function, where you don't have access to modify the function's prolog and epilog.

You said: "But in the first one I end method TIdIOHandler.RaiseConnClosedGracefully". That implied to me that you are directly calling RaiseConnClosedGracefully() yourself. If that is not the case, then ignore what I said. Indy will raise an EIdConnClosedGracefully exception when the extra client disconnects if it does not send a request.