Remy Lebeau

What is "auto passive mode"? Do you mean "Active" mode? "Active" (server connects to client) and "Passive" (client connects to server) are the 2 modes defined by the FTP protocol, and "Active" is the default. "Active" mode is not friendly to NATs, which are commonly used nowadays, so it is best to just always use "Passive" mode only.

That's the way I usually do it when I need an event handler without an object instance.

In general, RTL types named TXXXMethod refer to non-static class methods, and TXXXProcedure types refer to anonymous procedures.

Try using PROCESS_QUERY_LIMITED_INFORMATION instead. And do try using GetProcessImageFileName() or QueryFullProcessImageName() instead of GetModuleFileNameEx(). This approach should be more compatible with elevated processes.

You can't edit a post after some time has passed. And you can't delete a post, but you can flag a post and ask a moderator to delete it for you.

What exactly have you tried that is not working for you? Please show some code. Which API are you using to enumerate running processes? CreateToolhelp32Snapshot(), EnumProcesses(), EnumWindows()? Have you tried APIs like GetModuleFileNameEx(), GetProcessImageFileName(), QueryFullProcessImageName()?

The SysUtils unit in Delphi's RTL has AnsiDequotedStr() and AnsiExtractQuotedStr() functions for that exact purpose.

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).