Leaderboard

If the drawing code is too time consuming for being called in OnPaint, you might consider drawing to a bitmap when something changed and draw that bitmap in OnPaint.

That is not even required. I have now found Inno Setup does it all for you. We are getting way out of Delphi topic here, but this is what I now have in Inno Setup, and it does it all: Tools>Configure Sign Tools: signtool="C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool" sign /a /fd SHA256 $f [Setup] SignTool=SignTool [Files] Source: "*.exe"; DestDir: "{userappdata}\SARTrack\exe"; Flags: recursesubdirs ignoreversion signonce Source: "*"; Excludes: "*.exe"; DestDir: "{userappdata}\SARTrack\exe"; Flags: recursesubdirs ignoreversion (where \SARTrack\exe is my destination dir) This signs *all* executables, then it signs itself.

Something that is often overlooked is to limit the redraw frequency. If you redraw the display on every update and there are many updates per second, you may save a lot of time on triggering the invalidate at a capped rate, i.e. not do a full redraw every time, but update once every fixed time interval. Unless you are doing video processing - a redraw at maximum twice per second should be more than sufficient?

Maybe you are doing computation in the OnPaint event. Decouple computation from presentation (the drawing). For the drawing itself, avoid drawing pixel by pixel on screen. Avoid having hundreds of components to draw. Avoid drawing invisible parts. Painting in a bitmap and then blasting the bitmap on screen could be faster than painting on screen directly.

Thanks, David. That was indeed what caused the exception. I noticed that pattern at least once in the docs I read and forgot. The pattern above was based on Objective-C code samples I studied. However, mine does not work as intended because the notification handler is not called back. I did not know about Kastri until now. I'll pursue the Kastri solution if tinkering with my own implementation remains fruitless. In any case, I just became a Kastri sponsor on GitHub. Thanks again.

That is correct behavior. See, even Windows OS while loads and unload all the needed libraries (DLL) for application and their dependencies too, require explicit call to FreeLibrary if you called LoadLibrary on your own https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-freelibrary So the shortcoming from the RTL management from not reference counting the libraries from the manual load, i think it is a bless and prevent many hidden bugs and memory leaks, in other words you load it, you unload it.

Then you are likely doing too much work in your drawing code. Or you are doing other things besides just drawing. Painting should be a quick task. Draw only what can be seen for the current state of your existing data, nothing more. Do not manage your data/UI in any way other than drawing. If you need to manipulate your data/UI, that has to be done outside of a paint cycle. That is not how UI painting works. You have to draw whatever your current state represents. After the painting is finished, if a state change occurs, then you can trigger a repaint to draw the updated state. No. Every paint cycle is a complete redraw from scratch. For each window/control that is being painted, you have to draw it entirely in a single cycle. And then again in the next cycle. And so on. You can Invalidate() an individual form/control to trigger a new paint cycle for it, but that requires you to redraw it entirely from scratch when that next cycle begins,

My projects are all rather small, regardless of the platform and the tools I am using. I am personally using Android Studio with Java. Comparing to Delphi, Android Studio is way more resource hungry and slow. Opening a project takes more than a minute, building about 3 (also highly depends on how AS mood at the moment as rebuilding the same project can last up to 10 minutes). Similar Delphi sized project (actually a tad larger) opens up immediately, and builds in under a minute. AS gobbles up over 4 GB of memory while doing that and burns my CPU at 98%. While Delphi uses a little over 600 MB and 8% CPU. Also I had a AS bug report open for years before it was finally fixed, where it would eat up memory on opening second project, and crawl down to a halt and had to be killed through Task Manager. So if I had to switch projects I had to restart the IDE. I am sayin all this so that people wouldn't think that the grass is much greener on the other side and that there are no problems. But the IDE has more features than Delphi and it definitely has some I would want to have. My son is using IntelliJ for Java, and Rider for C# and he is very satisfied with both.

It's likely because you have an incompatible JDK present on the machine. This is a potential fix: 1. Make sure JAVA_HOME environment variable is set to the Adoptium JDK: JAVA_HOME=C:\Program Files\Eclipse Adoptium\jdk-11.0.15.10-hotspot 2. Add missing build-tools by going to: C:\Users\Public\Documents\Embarcadero\Studio\23.0\CatalogRepository\AndroidSDK-2525-23.0.50491.5718\cmdline-tools\latest\bin In a command prompt and issue these commands: sdkmanager “build-tools;33.0.2” sdkmanager “platforms;android-33”