1. How a style name is constructed

You’ll want to know this if you’re creating custom controls. If you don’t explicitly state a style name for your control (and you probably don’t want to) FireMonkey will search for a style based on te class name of your control - it removes the preceding ‘T’ and appends ‘Style’ to the end.

So, a TButton uses a style ‘ButtonStyle’. A TEdit, ‘EditStyle’, a TCalender ‘CalendarStyle’ and so on.

2. Style names can also be inherited

But if you’re subclassing a component you may not want to have to create a style for it if you haven’t modified anything which alters the styling. And if that’s the case you don’t need to.

If you create a component:

FireMonkey will first look for the style ‘EditChildStyle’ (as we saw above). If that doesn’t exist it will look for the style for the parent class, i.e, it will look for ‘EditStyle’ and apply that.

But, this doesn’t apply to grandchildren. If you then create:

FireMonkey will look for ‘EditGrandchildStyle’, then ‘EditChildStyle’, but it will stop there and not go any further up the component tree to ‘EditStyle’.

3. Loading default styles

The basic look of your application comes from the default style. If you want to change this you need to set the StyleFileName property of your forms Application object (in the FMX.Forms unit):

This is best done in your project file, before the line to Application.Initialize.

Ideally there should be some way to set the default style from within your applications project options, or to load it from a resource. Sadly, after much experimentation, I can’t find a way to do this. If you know better, please comment.

4. Where your application gets it’s styling info

As you know you can pop a StyleBook on a form to customise your style. But adding a separate stylebook to each and every form: duplicates data; increases redistributable sizes; is a mainainance nightmare (update every form when you change a style?); just isn’t DRY.

Much better to create a single master StyleBook on your main form, then link each child’s stylebook to that on the main form. You can do that with the following in each forms OnCreate event handler:[1]

Note, however that this doesn’t work within the form editor. Create a custom control, add it to your child form and it won’t show the style you have loaded in your main forms StyleBook. I really hope Embarcadero find some kind of workaround for this. Or better yet, improve the style book handling within FireMonkey.

5. Set your StyleBook property

This gotcha has caught me a few times: You add a StyleBook to your form, change the style within it, set your components StyleLookup property and run your application. And you get the default style.

You should have set the forms StyleBook property to point to the StyleBook. Ouch.

Note that if you right click a control and edit it’s style, a StyleBook will be created and the StyleBook property will be set, but only if there isn’t already a StyleBook present. If you create the StyleBook manually, you need to set the StyleBook property yourself.

6. You can have multiple StyleBook objects

Your form can have multiple StyleBook objects. I figure that explains the behaviour in the above item - FireMonkey doesn’t want to assume whcih StyleBook to use. Why would you want multiple StyleBooks? I’m not really sure. The form and the components on it can only use one at a time.

7. Styles don’t have to come from style files

So, you know a style can come from the default style, or from a StyleBook, but it can also come from a control on a from. Simply set the StyleName property of a control and set the StyleLookup of another control to match.

8. Keep your StyleBooks light

The resources in a StyleBook take time up at form create time. For this reason you should keep your StyleBooks to a reasonable size. Instead you should put styling information in your default style (and load it with Application.StyleFileName - see above).

Sadly at the moment there’s no easy way to merge style files - so you’ll have to add your custom styling to the (probably Embarcadero supplied) default style and keep the merge up to date.

9. Beware the HitTest

Add a TImage to a button and you’ll notice that when the mouse is over the image the functionality of the button will be lost. I.e. mouseovers, clicks etc will be ignored. This is because the TImage is absorbing them. To fix this you needs to set the TImage’s HitTest property to False. This applies whether you’re adding controls on a form or in a style file.

10. If all else fails, set Locked := True

Every FireMonkey control has a Locked property. I’m not sure what this does. The Embarcadero doesn’t seem to know what it does either, the property reference simply says it locks controls at design time, but this page says “Enabling Locked changes the way hit testing works and triggers fire, so that the subcomponent is part of the larger whole.”. My experience (although somewhat limited in this area) is that if I’m having problems with mouse clicks going missing fiddling with Locked in association with HitTest (see above) is the best way to resolve things.

[1] An even better way to handle this is to create a custom form class, and set the StyleBook property in an overridden Create constructor. This is left as an exercise for the ready.

Full change list:
Fixed: GradientPointsEditor text values update when gradient points are selected (Update 4 bug? ColorPanel.OnChange is no longer called when value is set programmatically).
Fixed: Added editor for TControl.Position.*
Fixed: R and B values where swapped in text fields of GradientPointsEditor.
Added: Text entry for ColorEditor.
Fixed: GradientPointsEditor gradient updates when changing text fields.
Fixed: Files other than current one not being saved on SaveAll or Close.
Fixed: Alpha value (text edit) updates properly when selecting gradient points (FMX bug workaround).
Added: Property editor styling is slightly better.

The full list of changes for this update:
Added: ‘Apply’ styles: One click to modify the style of a running FireMonkey application
Added EurekaLog error handling (some bugs with EL and FMX).

I saw no reason why I shouldn’t be able to do the same thing in FireMonkey. A FireMonkey list box is simply a container for other controls, so I reasoned I could simply replace the existing text control with an edit control when the user began an edit, and swap back to the text control when the edit was finished. We’ll start editing when the user hits F2, finish on pressing the enter key and let users back out by hitting escape.

Here’s a screenshot of what I came up with:

EditListBoxItem

A listbox is a container for other controls, but only children of TListBoxItem will actually show up within the list, so first we need to create such a child, we’ll call it TEditListBoxItem:

EditControl is the control which will do the editing. I could have explicitly made this a TEdit, but if we use a TSyledControl then users of our code can substitute any suitable control. They could use some kind of date or filtered editor, or one with validation. Or they could use something completely unrelated to text and text editing.

We’re relying on the creator of the list box item to create and assign the edit control. When they do we need to do some setting of properties, as shown above. We need to monitor the OnKeyDown event so we can intercept the Enter and Escape keys to finish editing.

Because we don’t know that our edit control will be an edit box we can’t simply read and write the Text property. Fortunately FireMonkey gives us a more generic way of getting and setting content using the Data property. This is a Variant and can read or write any data type as used by the control.

Note in the SetEditControl method above that we took care to preserve the value of any control already in existence by getting the old Data and assigning it to the new Control.

And refer back to the class definition above to see that we override the GetData and SetData methods to get and set data. We also add our own Text property since GetText and SetText aren’t virtual. Our GetText and SetText simply pass values to and from the edit controls Data property. It’s a bit redundant in our usage, but adding this functionality should help prevent obscure errors somewhere down the line.

TInPlaceEditListBox

Now we can move on to the list box itself:

We’ll start in the overridden KeyDown method, which simply monitors for the F2 key:

Here we,
* Check we have a valid ItemIndex.
* Stop any exising edits.
* Preserve the scollbar value so we can restore it later.
* EditUpdate is used to prevent some icky side effects (see below).
* We free any existing EditItem (our TEditListBoxItem), create a new one and call CreateEditControl to instantiate the control to go inside it.
* We preserve the existing ListBoxItem into EditedItem, so we can restore it once editing is complete.

Now we need to get our TEditListBoxItem (EditItem) into the list. TListBox has an InsertObject method to insert an item anywhere in the list. Unfortunately a bug in FireMonkey (as of XE2 update 4) means this always fails with an exception. The workaround for this is to call AddObject which adds the item to the end of the list (and is a synonym for setting the Parent property), and then call Exchange with the two items we want to swap.

EditItem (Our new item) is now in the correct place in the list, and EditedItem (the old text item) is now at the end. We can simply null EditedItems Parent property to remove it from the list.

Next comes a line lifted from the dark side, and one I’m not proud of. Recall our discussion on setting a generic data value through the Data property? What I should have been able to write here is

But the FireMonkey designers borxed things up in TListBoxItem by adding a fresh Data property of type TObject which, as far as I can see, isn’t actually used anywhere in FireMonkey.

The workaround is to explicitly call the inherited GetData and SetData methods which aren’t overridden in TListBoxItem, but they are hidden because they’re protected and out of scope. We can bring them into scope by creating a do nothing descendant of TListBoxItem (

) in our unit and use some typecasting as shown above to get to the methods. Like I say, nasty but necessary.

After that we can return to sunnier climes. We:
* Give the edit control focus.
* Select the new item, to restore the list boxes ItemIndex property.
* Restore the scrollbar to where it was.
* Animate the opacity property for a pretty effect.

Tidying up

To handle when the user finishes editing we use the EVKeyDown event handler which monitors for Escape and Enter keys and calls EndInPlaceEdit, which is pretty much a reversed copy of InPlaceEdit: swapping out our editor for whatever was there before and saving (or not) the Data.

There’s only a couple more things of note.

We override the SetItemIndex method to stop editing if another item is selected (e.g. by a mouse click). Here’s where our EditUpdate field comes in useful: all that inserting and moving list items around plays havoc with the ItemIndex property and we need to protect against accidentally finishing editing before we’ve even started.

In EVKeyDown we add code to move the editor when the user keys up or down:

but we double check ItemIndex can be changed. Otherwise moving up from the first item or down from the last would cause the editor to be recreated and look nasty.

Finally we’ll look at CreateEditControl which lets developers use their own edit control, or defaults to a TEdit:

Back to the list box item

Before I leave you in peace I’ve got something else to show you. Look at the constructor of TEditListBoxItem:

We’re setting the CanClip property to false. This means that the item and it’s children can show outside the bounds of it’s owner (the list box). The first effect of this is that the editors glow effect can show outside the list box. IMHO this simply looks better.

The second and potentially more exciting effect is that the editor itself can appear outside the listbox. Imagine the list box contained some potentially long strings but you don’t want a wide form. The user can now have a compact display but with a nice long edit box when necessary.

The code to achieve this is simple, in the list items SetEditControl method simply comment out the line that sets the Align property and set a reasonable width for the edit control:

Download the full source:

Enjoy, Mike.

Full Source

But MonkeyStyler is feature complete enough to have a beta release. I’m now working on the installer and those other little bits needed by a public product.

If you want to be among the first to try MonkeyStyler out you need to act now. I need a small number of volunteers for the beta test. If you’re interested, drop me an email to monkey@solentsoftware.com. Remember places are limited.

Enjoy.

Mike

Style elements are made up of components in the same way that your application is also made up of components. Indeed, the same components that are available in the component palette are also available in styles, although most of the components you will use are made up from the more ‘primitive’ components - shapes (TRectangle, TCircle, TPath) etc., animations and effects as well as TLayout and TText.

A typical style

Lets take a look at a typical FireMonkey style. The following is the component tree for a TButton in the windows 7 style:

(Note from the indentation above that certain components are children of other components.)

So, we start with a TLayout. This is a useful container component. It is similar to a TPanel, but has no ‘styling’ itself - ie. it has no way to specify it’s appearance (because it has no appearance).

The TLayout has three children, a TRectangle for the background, a TText for the text and a TGlowEffect to show selected state. Both of these are ‘styled’ components - ie that have an appearance which can be modified. A TRectangle, for instance, has stroke and fill ‘brushes’ for the outline and infill respectively, as well as properties for stroke thickness, corner type, which sides to show and much more besides.

The background rectangle contains another two rectangles, which add extra subtlely to the style, four animations and an effect.

Animations modify a property of their parent component. For example, when you hover your mouse over a button the background changes color due to an animation modifying the Fill.Color property. However, animations are not (necessarily) instant flips from one value to another. In the example just stated the fill color ‘animates’ gently from the original color to the target color over a fraction of a second.

In styles animations are usually activated by a boolean Trigger property, which is linked to the name of property on the parent component. When the trigger property changes state, the animation fires. There are a number of properties which can be used to trigger an animation including mouse overs and clicks.

Different animation components modify different types of property. A TFloatAnimation modifies a numeric property, a TColorAnimation modifies a color property, and so on.

Effects are similar to animations, in that the are tied to a trigger property and modify the appearance of the control when the trigger property is True. Effects can do things like display a glowing border (TGlowEffect), a drop shadow (TGlowEffect) or blur a control (TBlurEffect).

Styles and Components

So, above we have the component tree for a TButton in the Windows 7 style, but the tree is not fixed across styles: we could create a style with components added or removed, with components rearranged, even with components of different types. It is entirely up to the style designer to decide how a style element is made up.

However, there do need to be links between the developers code and the designers style. For example, when the developer sets the text of a TButton, he searches the buttonstyle for a component called ‘text’, expects that it is of type TText and sets it’s Text property. So, in this case the style must have a TText component called ‘text’ somewhere within it in order to provide the full functionality of the control. When designing styles (and the code to go with it) it is important that the designer and developer communicate and document any such links.

Other components

A style may also contain any component available on the Delphi/C++Builder component palette. For example, a TScrollBox contains two TScrollBar components, for the vertical and horizontal scroll bars. In such a case the component in the style file can be used to specify things such as the width and height of the component.

However, the styling for these control will be picked up from the usual style elements for that class of component (ie. ‘scrollbarstyle’ for a TScrollBar). You can, however, override the components default styling by setting it’s StyleLookup property and creating the appropriate style element.

So, in this post I’m going to cover the following:

• How FireMonkey grids work;
• How to create a custom cell class;
• How to create a custom column class;

Our StackOverflow poster wanted to know how to set the alignment and color of a grid cell, so I’ll concentrate on those issues in this post. We’ll create an app which has a grid showing two columns. The first will display the row index, the second financial figures, which are right aligned and with a background which changes to red when the figure is negative. I’ll cover most of that today with the styling issues in a future post.

FireMonkey Grids

Grids in FireMonkey are much more flexible than those in the VCL. But, of course with flexibility comes complexity. Fortunately, once you’ve learnt a few basics the rest comes fairly easy.

A FireMonkey TGrid is simply a container, adapted to contain children of type TColumn. A column is simply a container for a series of cells. We’ll get to the cells later.

To start with we’ll create an app which contains a TGrid. In the Delphi form designer, right click on the empty grid and select the Element Editor. Here, add a TColumn and back out. This will be a basic column in which we’ll display the row index.

On to the code, here’s the interface:

Data is a list which we populate with random values in PopulateData.

FormCreate sets up our Data values, and also creates and adds another TColumn to the grid. We’ll create this in code so it’s easier to play around with. Note that, as always in FireMonkey, we simply assign it’s Parent property to the grid to assign it to the appropriate container.

Go back to the form editor and create a method for the grids OnGetValue event:

What happens here? The TColumn has a number of cells to display data but it only creates as many cells as it has visible rows. I.e. if a grid has a RowCount of 100, but only 20 cells are visible then only 20 cells are created. Whenever you scroll the grid each cell gets recycled. Because of this a grid cell cannot store any data between refreshes. (Or, more accurately, it should not store data because if it does it will be displaying the wrong data).

So, every time a cell is displayed the grid calls the OnGetValue event for that cell. OnGetValue passes the column and row indexes for the cell (the virtual column and row indexes) and our event handler needs to return the value to display in the Value variant parameter.

Run the above and you’ll see something like:

(Aside: the grid appears to have a few display issues if you don’t show headers, hence why I’ve kept the headers here).

Custom Columns

Ignoring the rounding issues (we’re using Singles for simplicity here), you can see that the column of supposedly financial figures really needs to be right aligned (we’ll come to rounding and formating later).

We’re using a TColumn for the figures, which is a container for TTextCell. The definition for TTextCell is:

So, it’s just an edit control with the parent set to the column. Haha. Easy. To get our control right aligned we just need to set the TEdit’s TextAlign property, which we can assign when the cell is created.

Each cell is created in the columns CreateCellControl virtual method. Look for the method in TColumn and we see:

So, we’ll create our own custom column and override the CreateCellControl to do our work for us:

Update the FormCreate to create TFinancialColumn and we see:

Custom Cells

But we’ve now taken things as far as they can go with the built in TTextCell. It’s time to create our own cell class so we can really get things looking how we want.

Look again at the definition of TColumn.CreateCellControl. Note that it returns an object descending from TStyledControl. A TStyledControl is the parent of any control which can have styling applied. In other words, any visual control in FireMonkey. FireMonkey already does that with TCheckCell, TProgressCell and TImageCell for check boxes, progress bars and images.

And you can extend this to create custom cells using any control you like. You could go really freaky and use a list box or tree view within a cell. You probably wouldn’t want to, but FireMonkey is flexible enough to do it if you want. And all FireMonkey controls can own - be containers for - other controls. So you can create a cell which is made up of multiple controls.

Take a look at the property editor grid for MonkeyStyler in the screenshot below from the the preview images blog post and you’ll see that the values column contains:

• A TColorBox for color previews (the Fill.Color property);
• A TEdit (editable properties);
• A TCheckBox (boolean properties);
• A TButton (for the animation menu button and image)

with code to set each item’s Visible property depending on the data type.

TFinancialCell

But, enough showing off, lets get back to our financial column. The TTextCell is just a TEdit. Not much customisation we can do there. What we’ll do is create our cell as a TStyledControl which will contain an alClient aligned TEdit.

Now, look at the SetData method, which is the Setter for the Data property. Data is defined in TFMXObject, the parent of all FireMonkey objects. Earlier we saw how the grid fetches data for each cell by called the OnGetValue event, well after it’s fetched the data it passes it on to the cell objects Data property. So, we override the SetData method to get the data we need to display.

Before we can run things we need to update the columns CreateCellControl to reflect our new cell class:

Now things are looking much better:

Round up

So, we have a grid column which is formatting the data how we want. This article is already long enough, so I won’t bore you any longer, other than to say that I will return at some future point to show you how you can use styles to format the grid cells we created today.

Enjoy.

GridBasics.zip - Download the project sources.

Full source:

So, here’s the complete screenshot.

File and Element Manager
Lets deal with each area individually. First the file and element manager.

You can load a number of files at once, create new files, close and save open ones, and switch between files. The ability to have multiple files open means you can easily copy style elements between them (or indeed copy a style element within a file to create a duplicate).

(Note that I refer to individual elements within a style file as style elements or just elements. Hence the ‘buttonstyle’ for a TButton is one element, ‘checkboxstyle’ another and so on).

The element manager lists all available elements within the currently selected file and enables you to copy elements within and between files (as described above), create, delete and rename elements.

And, of course select elements, which shows the selected element in the control viewer:

Control Viewer

The control viewer shows a live preview of your style. Note here that you’re not actually looking at a TButton. You’re seeing the components which make up the style for one. You can’t actually interact with it (eg. mouseovers, clicks etc. do nothing), but the Components button shows the drop down shown in the screenshot.

With this components drop-down you can see which components make up a style. You can also show and hide individual components by checking or clearing the relevant check box. This is a great way to see how a style is actually made up.

A neat feature is that the check boxes for animations and effects run the animation or effect. Have an animation which takes a second to run and you will see it running for a second in the preview. In other words, while the preview may not be an actual control, all the components (and animations and effects) which make it up are ‘live’ and working. An animation which is set to loop will be constantly running and looping in the preview.

Property Editor

And finally, we come to the property editor. This should all look pretty familiar from Delphi/C++ Builder. Use the drop down to select which component within the element to edit and it’s properties will be displayed. Sub-properties can be expanded and edited as you would expect.

As for editing properties there is one feature you’ll notice immediately: all edits are live. Start typing into a ‘Text’ property and the text on the control preview will change live as you type. Adjust the width, alignment or cornerstyle (or anything else) and the preview will update immediately, and without the need to hit enter, or otherwise tab away from the editor.

Another useful feature is the drop-down property editors. Edit a numeric property and you’ll see a slider appear, for a color or gradient property you’ll get a drop down color or gradient editor and so on. And these are also live: you’ll see preview control change live as you drag the slider, adjust colors or edit the gradient. There’s no modal dialog. No need to hit enter. You get instant feedback and quickly get the values you want. (And even if you have a drop down editor, you are still free to type in/cut and paste values if you want).

You also get:
A button which brings down a menu for adding/editing animations;
No nasty modal error messages. Set an illegal value and you’ll get a drop-down error message which simply clears as you keep typing;
Buttons to add and delete components.

And, like I said, much will change, much will improve and much will be added.

Enjoy.

MonkeyRecolor is my answer to this. It is a simple product which enables you to take any FireMonkey style and radically changes it’s color scheme just by tweaking a few controls and clicking a single button. MonkeyRecolor can create serious business styles, either light or dark, or it can create bright and colorful styles which can really make your software ‘pop’.

You get a set of controls for adjusting the colors of six different elements of a scheme, from backgrounds to highlights and selections to glow effects. Hues for secondary colors can be based on the background hue, in which case MonkeyRecolor pretty much guarantees a scheme which adheres to the rules of color theory, or you can go off piste and set any colors your heart desires.

Subtle variations in the original schemes colors are respected and retained. For instance the subtle change of hue across a button face will be retained, albeit with a different base hue. This applies to all colors within the style. It also applies to the colors used by animations and effects.

MonkeyRecolor is supplied as a form which you can attach to a Delphi or C++Builder project. Set a couple of properties and create a link from a menu item or button and you are ready to go. You can (and should) remove the links when you are ready to redistribute your software. The download also includes a pre-built application which can be used to load, edit and save default styles.

‘Schemes’ are settings for MonkeyRecolor. These can be saved a re-loaded so you can save data between sessions or to tweak later.

The application of color changes is controlled by a config file. The ‘language’ used by the file can be used to specify almost any component or group of components and can thus be used to modify how a scheme is applied to styles.

MonkeyRecolor is a free application supplied with full source code.

Read more.

Or see the wiki for instructions.

More to come soon.

Mike