Leaderboard

Creating at run-time is pretty straightforward. You need Owner and Parent, and sometimes setting Align property. You can use any FMX control as those - or at least I have been able to use them without a problem. FFrame := TMyFrameClass.Create(AParent); FFrame.Parent := AParent; FFrame.Align := ... And that is it.

When creating frames runtime in VCL, there are a set of tweaks that need to be applied to make the frame behave properly after creation (setting parent/owner etc). Are there similar tricks needed for FireMonkey, and are there other pitfalls related to dynamically creating frames at runtime? Is it better to drop the frames on the main form at design time?

That's why I did not use frames at all... But with FMX there is no need for a "frame". For every content I create a Form with a TLayout. If there is any need to uses this content on a other form/tab/whatever, you just have to set the parent of the layout to the e.g. tab or any other layout on any other form. So easy... Frank

I was also hesitating to use Frames for many years, from some bad experieces under VCL, and especially in Designmode. For FMX I use Frames in some places very successfully, where I use designer to design them same like a form, and loading only via runtime into TRectangles. I checked also other carriers, like TPanel, TLayout, they all seems to work well. Since also the TFrameStand uses Frames as visual container, I feel quite sure about them now. I also use Interface with Frames, so that I'm able to create the frame in a factory, and using them via Interface elsewhere. Still I don't use Frames in Designmode, like dropping a component, since I think there are a lot of misconceptions. With good encapsulations, at runtime, they behave quite well, and I even can embed frames into frames in same way. Rollo

The anonymous procedure helps to keep your app responsive, instead just showing a modal dialog or form. This is required on mobile devices, but I also highly recommend to use the same strategy for desktop too. There are many other methods to prevent unwanted user actions while the dialog is shown, beside modal dialogs and forms.

You're wearing out the cosine instruction on the CPU. :-)

@haentschman It's always better to have named constants instead of numbers. Say you want to swap 2nd and 6th bits in some structure's field. Then you need to scan all your program and check all places where these bits are used. But if you used an enumeration from the start, you just swap these bits in the declaration: type TMyEnum = (mb0, mb5, mb2, mb3, mb4, mb1, mb6, mb7); Of course instead of mb0, mb1 etc. should be really meaningful names, without numbers.

I have an old project in maintenance. This is full of bit operations. If you don't work with it permanently, you want meaningful names.

You can write it as If ((b and $01) > 0) or ((b and $08) > 0) or ((b and $80) > 0) then ... Or you can create an enumeration and use meaningful names for each bit. type TMyEnum = (mb0, mb1, mb2, mb3, mb4, mb5, mb6, mb7); TMyBits = set of TMyEnum; // = Byte in size function Test: Byte; var mbs: TMyBits; begin mbs := [mb0, mb3, mb7]; Byte(mbs) := $89; // It's equivalent of mbs := [mb0, mb3, mb7]; if mbs * [mb0, mb3, mb7] <> [] then // If one of bit is set ;//... if mbs * [mb0, mb3, mb7] = [mb0, mb3, mb7] then // If all 3 bits are set ;//... if mbs - [mb0, mb3, mb7] = [] then // If no other bits are set ;//... Include(mbs, mb1); // Set 2nd bit mbs := mbs - [mb3, mb7]; // Unset 4th and 8th bit //etc... Result := Byte(mbs); end; It's always better to deal with clearly named typed variables and constants.