havrlisan

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).

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.

Is it possible to use attributes in these scenarios: // First scenario [MyAttr] TMyGuid = TGuid; // Second scenario [MyAttr] TMyDT = TDateTime; I found this article that says it's not possible to use attributes on aliases of simple ordinal types, only on actual sub-types by using the type keyword. I'm asking this because I believe declaring my TMyGuid type as a sub-type for TGuid rather than an alias will break a lot of my code. Is there really no way to use attributes on aliases like this? Update: I realized that changing my declaration to TMyGuid = type TGuid; will only cause the loss of TGuidHelper. Unfortunately, class helper inheritance is still not available so I will have to rewrite it for my sub-type.

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

Unfortunately no. The only option left is to factory reset my phone, but I doubt I'll do that.

Perhaps. I tried setting up a wireless debugging option, maybe that's what messed up the configuration. Weird behavior, but I believe I tried everything except factory reset.