Dalija Prasnikar

Interesting... as non native English speaker, I guess I don't immediately see the difference. Above pairing generally makes sense. In this case, from my perspective TrimBeginning is extremely awkward to write.

Android API moved from such ambiguous methods and properties named left/right to start/end so following that rule it would be TrimEnd and TrimStart

As long as we have power, all is good

You can also try disabling package cache, it helped in my case. You need to edit registry key HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Package Cache and then set the DisableAll value to 1. If it does not exist add new DWORD value with that name. But 10-12 seconds is really long time. Maybe something else is in play. If disabling Live Bindings and package cache does not help I would recommend filing bug report at https://quality.embarcadero.com/

Locks of any kind used as field in a class are meant to protect integrity of the data inside object instance, not to protect that instance from being destroyed. If you need to protect particular TMyClass instance itself, you will need to use some outer locking mechanism.

The most similar would be Delphi XE, but that is not a long jump 🙂 Every new version has some features and some differences, and you will need to tweak some code to adjust in order to benefit from those features. The more recent version you use, the less future tweaking will be required. From that perspective, probably the most stable recent version is Tokyo - 10.2.3. Rio - 10.3.3 is also quite usable, but it does have less stable debugger, and new IDE styling can cause performance issues on low end machines. All those versions have better support for using high DPI in your applications. If high DPI is not imperative for you, and you are less inclined to make huge jump, then XE7 is probably the most stable version in between. XE7 is also good option if your code uses class helper for gaining access to private class members, since that was removed in Berlin 10.1.

While 10.4.2 is a bit unstable (fortunately, my code does not choke it too often), going down to D2010 seems like overkill. There are many stable releases in between you can productively work with, and then move to 10.4.2 when patched.

OK, long timeout was a bit confusing and I could not determine how long each operation should last. As far as I can see there are no obvious reasons why your approach fails with timeout. It is a bit longish code, so I am not excluding possibility of not catching error in code and possibility of some memory corruption, but that would commonly show much sooner. Using TTask and reusing threads through its thread pool is definitely faster and more correct approach comparing to creating anonymous threads. Anonymous threads was "fallback" suggestion in case your overall time spent in calculation is long enough so that creating thread overhead pays off. If the TTask is really the issue here (which is also hard to say) another option would be trying some other library. One thing you probably can confirm, by using anonymous threads is that TTask is the culprit here (even though you can never say that with 100% certainty).

Since, your timeout is quite large, I suppose your requirement is not real-time resizing. In that case AnonymousThread approach can be good enough. I would also suggest using TTask wait without timeout, but 10 seconds is quite long time period, so it is quite possible there are other problems with TTask, and that using no timeout would just hang indefinitely (it might be worth trying, though). If the AnonymousThread approach is not good enough (creating and starting thread takes time - not much, but still) then creating reusable dedicated threads that would take care of resampling could be an option. But that is the most complicated approach, because you would need to communicate back and forth with such long running threads and pass data in and out as it finishes processing pieces of data. It is possible that there are libraries that have something you can reuse - the first place I would look for is OmniThreadLibrary https://github.com/gabr42/OmniThreadLibrary

Without going into the why you are getting timeout, could be the issue @Vandrovnik mentioned, could be something else. Depends on your machine, number of cores, system activity too. But, if you are resampling video frames, that suggests that you are resizing same sized frames to same output size. In that case, calculating contributor weights for each frame again is huge waste. Calculate that once, and then just reuse it.

Ouch.... I wish you full recovery.... I would also say speedy, but you don't recover fast from that thingy.... I also had mild symptoms (I had way worse flu infections), but fatigue is beyond extreme... I literally slept for a month. Absolutely. It is quite bad experience even with mild symptoms.

I suggest that you read once again what @Remy Lebeau posted. You example is horrible and no amount of dancing around it will ever make it work properly. When you run it, and it works... that will only be an illusion caused by undefined behavior and a touch of luck.

And that is exactly the situation OP has encountered here. I guess you missed that part.

No. It is not OK. You are trying to release the form twice. Once explicitly by calling Free and once by setting on close Action to caFree. This may work under some circumstances, like @balabuev mentioned caFree triggers posting CM_RELEASE message to the form window handle. If there is no code that will pump the message queue (like Application.ProcessMessages) between the time OnFormClose is called and your explicit call to Free, then calling Free will actually destroy the form and along with it its window handle and message posted to that handle will be discarded because window no longer exists. However, if CM_RELEASE message is processed and handled before your explicit Free call, form will already be destroyed at the point you call Free and hence the error you are seeing (presumably from EurekaLog) Because you have added some other code in between that is calling Application.ProcessMessages. You have to choose one option. Either you will use caFree or you will use Free. Using both and hoping for the best is not good option even if it works, because it can be easily broken, which you now have first hand experience. If you need to retrieve some value from the form after it is closed, then you shouldn't use caFree anyway because you may access dead form - again depending on the other surrounding code. Another reason to explicitly Free form is that this makes memory management more obvious. You create form, do something with it, and then you release it.

ShowModal is not supported on Android and it is not recommended on iOS, and if you trust documentations it should be safe to use on macOS. Issue is most likely caused by some other code, not your general form handling code that you have here. http://docwiki.embarcadero.com/Libraries/Sydney/en/FMX.Forms.TCommonCustomForm.ShowModal Your form handling is mostly correct. I would remove SaveFormPos from finally block because if something goes wrong you most likely don't want to save your form position. Also, if SaveFormPos can raise an exception, you will leak the form because FreeAndNil will not be called in that case. Also I would put f.var assignment inside try... block, because if that assignment raises and exception you will also leak form. And since form variable f is local variable and it is going out of scope right after you are releasing it, there is very little point in calling FreeAndNil, simple f.Free is enough.

Generally, books are the best resource for learning any language. More experienced developers can usually get they way around new language faster, so official documentation might suffice. Anyway, Delphi Language Guide is always a good place to start http://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi_Language_Guide_Index

CB can use most of the Delphi code, but not all.

Yeah... but making a wrapper around C++ lib....

It would probably be easier to write the whole thing from scratch in Delphi.

I meant wrong time. Let me explain. procedure TMainForm.OnTimer(Sender: TObject); begin ChangeFooBarForkState; end; procedure TMainForm.BtnClick1(Sender: TObject); begin DoFoo; DoBar; DoFork; end; procedure TMainForm.BtnClick2(Sender: TObject); begin DoFoo; Application.ProcessMessages; DoBar; Application.ProcessMessages; DoFork; end; Let's say that DoFoo, DoBar and DoFork depend on some state that is changed on timer with ChangeFooBarForkState and if you call DoFoo, DoBar and DoFork in sequence with different state you will get wrong result. In BtnClick1 without ProcessMessages, those procedures will run serially without interruption and with consistent state, because OnTimer event cannnot run in the middle, but in BtnClick2 timer can be triggered and can mess up that state. Now, this is a bit contrived example and you can say that you can fix such code to work properly with timer, but the point is that just like thread safety can sometimes be tricky because code may work properly most of the time, ProcessMessages can also be tricky to do right because you have to think about all the potential messages that can be processed and it can be easy to overlook some and you may have random bad behavior that is hard to reproduce. Now, this timer example is based on real life scenario someone had somewhere, where Application.ProcessMessages was the problem, I just don't remember where I read about it or what was exact code in question.

I currently have API 29, but I am testing Delphi Android applications only on Android 7.0 device. I am not actively developing on Android with Delphi. When I started Delphi for Android was not suitable for my use case and didn't have support for devices I needed, so I had to use Android Studio.

Modal dialog will prevent user triggering actions, but it will not prevent triggering timers (if you have one) from causing possible unintended actions running at wrong time.

Upgrading the SDK opens possibility for incompatibilities. Applications with lower SDK version run in compatibility mode on newer versions of the OS. When you increase SDK version you are basically saying this application supports all new OS APIs. If your application (that includes RTL and FXM) does not support all new APIs it can crash or malfunction. See: https://quality.embarcadero.com/browse/RSP-27218 This issue has been resolved in 10.4 Sydney and Android 11 is now officially supported by Delphi. I am not sure if there are any other issues.

When I said put your code in background thread, I didn't mean literally like run exactly the same code in background thread. But for any code that runs long, Application.ProcessMessages is always the wrong solution. It may be quick fix at some point, but it is still a wrong solution. First step in writing better code is acknowledging that Application.ProcessMessages is wrong solution. Then and only then one can start going in different direction and start learning and applying better solutions. It can be long process, depending on the existing code you (I don't literally mean you) already have. But the sooner you start, the less work you will have in the future when you start removing Application.ProcessMessages. If you never start doing that, sooner or later you will encounter code where Application.ProcessMessages will not work as intended and you will not be able to make UI fully responsive when using it. Learning how to use background threads at that point - when you cannot properly take time to experiment and learn will only make it harder. It depends, but certainly more often than with Application.ProcessMessages approach.

Yes, it does. Until some timer throws you a curved ball. Yes, it is possible to polish Application.ProcessMessages approach and solve reentrancy issues around it. That still makes it a poor solution because you still have other problems I mentioned before.