Introduction to FireMonkey - FireMonkey Guide

Back to Contents

FireMonkey (or FMX) is a set of components developed by Embarcadero Technologies for developing cross platform applications. It currently targets Windows 32-bit, Windows 64-bit and Mac and will shortly be extended to iOS (iPhone, iPad) and Android with the possibility of more target platforms being added in the future.

If you have used Delphi before the XE2 edition you are probably used to refering to the entire set of libraries as the VCL (Visual Component Library). With XE2 and the introduction of FireMonkey the libraries are now broadly divided into three parts.

VCLVisual components for exclusively Windows development. These will not be mentioned in this text. Units containing VCL components are prefixed VCL.
FMX/FireMonkeyVisual components for cross-platform development. This is the core focus of this text. Units containing FireMonkey components are prefixed FMX.
Non-visual componentsComponents which can be used by applications either for VCL or FMX development and for either Windows, Mac or Mobile. The units containing these components have a variety of prefixes. Some of these components have a close relationship with visual development and are commonly used on forms (i.e. timers and bindings) and will be discussed where they are applied to the FireMonkey libraries. Others, such as generics, are used chiefly in code, rather than visual, development and will not be discussed here although they will be used in examples. If you want to learn more about them, study one or more of the references in the Further Reading section.

There are three basic philosophies behind the FireMonkey framework: control emulation, the child-parent relationship and styling. These will be discussed below.

Control Emulation

Any GUI framework can work in one of two ways: using OS controls or emulating controls.

The VCL uses the first method, using operating system controls. In the VCL, TButton is a wrapper around Window’s own button control with a set of properties, methods and events which abstract away the finer details of working with the controls.

FireMonkey uses the latter method, everything you see and interract with is an emulation of the controls built into the operating system. In other words, a TButton is built from the ground up within the FireMonkey framework.

The benefit of doing things this way is that FireMonkey can take the same code and use a different style on each target platform so the controls look the same as the native controls. The downside is that if the styling or emulation are less than perfect your application may look or function slightly differently to mative apps. The detailed pros anc cons of this are for others to discuss, but are something you should be aware of.

The Child-Parent Relationship

In the VCL some controls can act as containers for other controls, e.g. panels and pagecontrols. In FireMonkey all controls can act as containers, and can contain any other controls.

So, for instance, you can take a button and add an image as a child so that you have a button which uses an icon rather than text. You can take a TEdit and add a button to clear it’s contents. On a FireMonkey form you could make your edit boxes and other controls as children of their respective labels so that, when you reposition the labels the controls maintain their relative positions.

This principal extends much deeper into the FireMonkey library. A listbox contains a list of TListBoxItem components and each of those items can be styled or subclassed to contain other controls. It’s easy work to create a listbox with colour samples, check boxes, clickable hotlinks, images etc. just by adding different child controls. And this same principal extends to other components such as tree views and grids.

Another example is the combo box which has a TListBox as one of it’s children and it is this which is shown when the combo box is dropped down.

This parenting principle is also the basis of the way the styling system works.


In the VCL the appearence of controls is defined by the operating system. In FireMonkey the appearance is completely controlled by FireMonkey. This means the appearance can be changed to suit the current operating system, or completely customised.

In the VCL you can get a custom appearance for your controls by using the built in (since XE2) VCL styles or a third party skinning library which will use bitmaps to redefine the appearance of your controls.

In FireMonkey the appearance of your controls is defined by each control’s style. Indeed, without a style a control would have no appearance (and, even, no functionality). A style is built up from drawing primitives (rectangles, text etc.) and other components (buttons, panels etc.). For example the style for a panel is simply a TRectangle. That for a button contains rectangles (or images if using bitmap styles), text, animations and effects.

The important concept to get when working with FireMonkey styles is that you are using the exact same components and primitives which you place on a form, using the same parenting concepts we discussed above. We used the example above of adding an image to a button. Do that with the style and every button (which uses the style) will have an image on it.

The concept (and power) of FireMonkey styles is probably overwhelming you at the moment but I’ll go into further detail in the Styles section. If you are to make the most of FireMonkey an understanding of styles is essential so I highly recommend you take the time to learn about them.

div title=