Leaderboard

That's okay. I don't mind critique. I don't think I was being impolite; I was direct. I assumed that the OP was a hobby programmer (or not a professional) since: He needed to ask the question at all. He used 24 years old code copied verbatim from experts-exchange. Code that anyone with a bit of experience should be able to write on their own. He didn't provide any details about the exception such as where it occurred, call stack, etc. which to me shows that he might be able to read code but doesn't understand debugging. Hence the suggestion that he learns how to debug. Next step would be to explain how to debug.

https://joeduffyblog.com/2006/08/22/priorityinduced-starvation-why-sleep1-is-better-than-sleep0-and-the-windows-balance-set-manager/

The behavior of the Sleep function was changed in Windows Server 2003, making it safe to use Sleep(0) — unless you're writing code for Windows XP. https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-sleep

Just because modern OpenSSL is not directly in Indy itself yet does not mean there are no options for it at all. For example: https://github.com/JPeterMugaas/TaurusTLS Did you see this? https://www.indyproject.org/2024/10/20/sasl-oauth-support-finally-added-to-master/

FWIW, my wife who speaks "human" tells me that my directness was indeed impolite. So sorry, I guess.

Usually you connect the actions of such a TActionList to some visual control of a form (TMainMenu, TPopupMenu, TToolBar, TTreeView, TListView ...). Most of these controls have their own property to connect a TVirtualImageList, which should reside on the form itself. The latter is mandatory to make DPI awareness work properly. It may sound wrong to have separate virtual image lists in each form, which often contain the same content - sometimes the same as the one connected to the ActionList. If you imagine that each each image list can only hold one size of images and each form can have run on a different DPI it becomes clear that this is unavoidable. While it can be tedious to have all these TVirtualImagelist instances at design time, there are ways to simplify it. If you are interested I suggest reading my blog posts about ImageLists and High DPI

I agree; most cross-platform apps nowadays have the same style across platforms. The FMX's approach to style objects with the png is rather stale as well; one should turn to using vector images. This is possible with zx-skiacomponents, which approaches the StyleObjects differently, allowing you to use direct properties for changing colors, animated images, or text settings on triggers. The feature I used the most was the SVG override color change, it allows you to create a beautiful yet responsive UI with no pixelization to worry about.

Turned out in the end I needed to follow these steps. Your applicationName.dproj needs to look like - <Platform Condition="'$(Platform)'==''">Android</Platform> <PlatformSDK Condition="'$(PlatformSDK)'=='' And '$(Platform)'=='Android64'">AndroidSDK26.1.1_64bit.sdk</PlatformSDK>

It is absolutely ridiculous that Embarcadero do not provide download links to the versions of the SDK and NDK that is compatible with each version of the Delphi IDE. There should be a Git Package for each Delphi Version. The amount of time I have wasted trying to get Delphi 12.2 to build an Android App which was previously building with Delphi 12.1 is just ridiculous! Does anyone have a List of Steps to follow that will work to upgrade the Delphi Delphi 12.2 SDK and NDK Currently I have this setup. Thank you in advance.

Thanks, but that was already clear. The problem is, that simulators are not behaving exactly like devices, especially with sensors and hardware stuff, this is why I rarely use them.

Have you seen the IDE using a phone booth recently?