Leaderboard

Yes, and not only that, but it allocates its own window internally to handle those messages. So it doesn't really matter if you create your own window or not, each window will handle only its own messages, but everything is going through a single message queue. Creating your own window will not cause such issues for TTimer. And your own window will not pick up any messages that are not specifically targeting that window. It is, however, possible that your own messages can cause delays in TTimer, because WM_TIMER is a low-priority synthesized message, so it will not be generated until the message queue is idle, unless you force it. So don't overwhelm the message queue unnecessarily, regardless of which windows are involved.

That is waaay to familiar. As a developer, you never run out of chances to own yourself.

Thank you @Dalija Prasnikar, I learned some new things about window messages! Unfortunately though, none of the above applied to my case. After the comment of @Lars Fosdal I got rid of the TTimer and used the same dummy window to catch the now manually fired SetTimer messages too. I also included a counter which increases each time a window message is received (whether processed or not) to see how swarmed application is. With a timer of 1 second, 70 seconds of runtime I got 72 messages. 1 is UM_WORKERENDED, I count the extra 1 as an acceptable discrepancy due to the timer's accuracy (or something unprocessed). So no, it was not the window messages. The solution is so painfully trivial I'm almost afraid to share... In the TComponent my timer was set to 750 msec to update the elapsed time on the UI. As I'm using TStopWatch, I manually converted the .ElapsedMilliSeconds to some readable format... using dividing and substracting. First time the timer fired at 0,75 seconds, UI was updated with the rounded 0 seconds. Second time the timer fired at 1,5 seconds, UI was updated with the rounded 1 seconds. Third time the timer fired at 2,25 seconds, UI was updated with the rounded 2 seconds. Fourth time the timer fired at 3 seconds, UI was updated with the rounded 3 seconds. Fourth time the timer fired at 3,75 seconds, UI was updated with the rounded 3 seconds. Even if the timer component is spot on it can be seen that every 3 seconds, for 2 seconds the elapsed time does "not update"... thus the feeling of variable speed. After upping the sampling to 1000 msec instead of 750 and some small tweaks to the conversion everything seems to be working fine. Why it was working on the TPanel...? Because originally I forgot to change the default 1000 msec interval to 750... What a nice way to waste a day by debugging something, which is working as it should 🙂

Processing messages for whole application happens in one place. WM_TIMER is low priority message and it will be dispatched only after all higher priority messages are dispatched. The fact that WM_TIMER messages are not being processed fast enough means that you application is either flooded with messages or is doing to much work in main thread, including code called with TThread.Synchronize and TThread.Queue. Changing from TPanel to TObject with allocated handle should not have any impact on processing speed. Also using WM_TIMER for progress is usually poor approach, it is better that you send status from the thread when you have some significant change to show. Additionally, if you are sending messages from OnTerminate event then you don't need to wait on thread (also freeing the thread will also wait). It is hard to say more without having reproducible example.

Hi, next time please chose a more specific subject for your question. 😉

To clarify: Android 11 is supported. The distinction is in the value for targetSdkVersion that ends up in AndroidManifest.xml (currently, the value is set to 29, as opposed to 30). A targetSdkVersion of 30 is yet to be fully supported, as it requires changes to the support of accessing external storage (and possibly other aspects of API 30). This is what is being referred to with a statement of: They really should make the distinction if they are saying it like that. Also, targeting an API level (via targetSdkVersion) and building against an API level are 2 completely different things, so downloading platform API level 30 and changing the SDK settings to suit is not the same as changing the target.

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.