havrlisan

Very good explanation, thank you!

That's just unnecessarily complicating things. I'd generally declare the variable before the loop (whether it be before begin or as an inline variable, it doesn't matter), I am just wondering if the compiler is able to interpret the variable declaration as it should (?) in loops.

Will there be any issues with declaring inline variables inside loops? Here's an example: procedure Sample(const AFixedArray: TSomeFixedArray); begin for var I = 0 to 10 do begin var LInlineVariable := TSomeFixedArray[I]; // do something end end Is it possible that the compiler will allocate more memory than needed, or something in that context? This seems to me like the only way the inline variable feature may produce issues.

You should add the following in your manifest file: android:exported="true" Here's a pretty good explanation for that: https://www.cafonsomota.xyz/android-12-dont-forget-to-set-android-exported-on-yout-activities-services-and-receivers/

When they say they support Android 13, I believe they mean that you can build an application for that version. However, that does not mean they actually have the latest SDK. You can build apps for Android 13 with older SDK versions, such as the one that Embarcadero provides with RAD studio installation, Android SDK 25.2.5. I highly doubt they'll upgrade their SDK anytime soon as that means they'll have to update all the java interfaces written in Delphi (Androidapi units) and add new ones. That's too much work for them, considering they focus on sales rather than fixing and updating the current code. After all, someone must catch the ChatGPT train! 🤮

Here you go https://quality.embarcadero.com/browse/RSP-40714

The Sync edit highlight always seems on top, even though the current selection should be on top. Here's a better screenshot to understand what I'm trying to say: The selected text is = Some text to

This seems to be a similar issue, but starting from 11.3, initializing a code template (ie. for template) will now mark the "fields to fill" with another shade of blue, that overthrows the selection color. Try creating the template, write some text in the fill field, and try selecting it with ctrl+arrows. This is what I mean: As soon as RAD studio lost focus (I switched to my browser), the template fill fields disappeared, and this is left: This is a bug obviously, but did someone find a workaround?

For those who had the same issue, it seems that the 11.3 update fixed it. Sometimes though, I have to first install the app on the phone, then go to Developer options and select that app in the Wait for debugger to connect option.

If by caveats you're referring to forced canvas locking or unpredictable behavior, then "can be created" doesn't really mean anything. Creating TBitmap creates TBitmapImage, which calls CanvasClass.InitializeBitmap() method that initializes a bitmap handle that is specific to the graphics engine. In Windows case, the class is TD2DBitmapHandle, and wouldn't you know, this is in its constructor: FContextLostId := TMessageManager.DefaultManager.SubscribeToMessage(TContextLostMessage, ContextLostHandler); and it all goes down the drain.

This is exactly what I was asking for, thank you very much for the explanation. I got some things mixed up in my head and started concluding that such implementation may be beneficial, hence why I asked about it. My initial thought was that TBitmap should be creatable and drawable in a background thread, but that doesn't seem possible because of global Canvas lock, and IIRC it also uses the TMessageManager (and that's where I expanded my opinion to all other components). That seems like a good idea, no?

Thanks for the detailed explanation. So if I understood correctly, FMX is designed in such a way that it is nearly impossible to separate the rendering part (which is done in the main thread) from the rest of the code? If, for example, one would rewrite the framework from scratch, would it be possible to separate the whole control creation and manipulation from the actual canvas drawing? To my understanding, the only part that must be run in the main thread is the drawing on canvas (which directly uses graphics API).

I'm aware that the creation and manipulation of FireMonkey controls are not thread-safe, but what does it take for Embarcadero to fix/reimplement to enable this behavior? I've gathered that the main issues most certainly arise from using the TList class without locks, such as TFmxObject.FChildren and TComponent.FComponents. Besides the properties, there's also the TMessageManager.Default which returns an instance of TFixedMessageManager, which is also not thread-safe (because it also uses TList without any locks). Besides these, what else could be an issue?

You can add TListBoxItem controls to TComboBox, for example: procedure TForm1.AddComboBoxItem(const AText: String; const AImageIndex: Integer); var LItem: TListBoxItem; begin TComboBox1.BeginUpdate; LItem := TListBoxItem.Create(TComboBox1); LItem.Parent := TComboBox1; LItem.Images := TImageList1; LItem.ImageIndex := AImageIndex; LItem.Text := AText; TComboBox1.EndUpdate; end; TComboBox will use these exactly the same if you were to put strings in TComboBox.Items. LItem.Images is a property to which you assign a TImageList control, in which you can add images. By assigning LItem.ImageIndex, you will then use the image you defined at that index inside the TImageList. Another option is to define an FMX style in TStyleBook and directly put the image there, but that might be redundant for this specific scenario. Unsure of which approach is better in general, but I prefer the latter one as it is more convenient to use in multiple places. Really depends on what you need though.

I see, so it is not possible to declare attributes for aliases. Thanks for your answer.