For a current project, I needed more like a balloon help in place of tooltips and therefore decided not to use Flex default tooltips.

Regarding usability of the tooltips (balloon help) I want to be able to

• Display an optional tooltip title
• Display formatted tooltip text
• Display icons
• Colorize the tooltip based on the semantic of the invoking control
• Consistent Placement
• Have all title, text, styles for the tooltips stored in a central location
• Have the tooltips work in a generic and Flex-compliant way

Flex gives you a few ways to customize tooltips from registering your custom ToolTip class to intercepting Tooltip events where you can hook up the custom tooltip. All of these approaches fall either short of the requirements I had or would add additional overhead so I simply created a custom ToolTipManager that would alter the behaviour of the default ToolTipManager.

Here’s a demo of the final result, the approch is described further down.

Since I like to have all resources centralized, the approach I followed was to interpret the value of the tooltip- or the errorString property on a control not as the tooltip text to display but as a partial key to lookup title, text, styles etc. in a resource bundle. Form this partial key concrete keys would be derived to lookup the values for a controls tooltip.

For example

<s:Button label=”OK” tooltip=”ToolTipBundle.okButton” />

would point to the ResourceBundle named  ‘ToolTipBundle’ and within this to all entries of a key starting with tooltip.okButton. Then the values for title, text etc. will be looked up by the custom ToolTipManager implementation and be applied to the tooltip.

The first token in the tooltip property specifies the name of the resource bundle, the second token the partial key for looking up the entries in the resource bundle. If no second token is specified the id (if any) of the component is being used.

Entries in the resource bundle then refer to the partial key submitted and define the concrete values to use for the tooltip.

tooltip.okButton.title=Title of Tooltip
tooltip.okButton.text=Text for this tooltip
tooltip.okButton.styleName=CSS class to use for this tooltip
tooltip.okButton.placement=bottomRight|bottomLeft|topRight|topLeft
tooltip.okButton.color=Color of text
tooltip.okButton.chromeColor=Color of tooltip

Color and chromeColor are there for convenience but can also be set via the CSS class specified by styleName. If any of the entries are not specified fallbacks to default values are used.

To make this work some methods of the default ToolTipManager need to be overwritten

override mx_internal function initializeTip():void

This is where the cstom implementation looks up the values and assigns them to the tooltip.

Additionally there’s the

override mx_internal function positionTip():void

method to position the tooltip in a custom way.

The custom ToolTipManager implementation is registered at loading using a custom preloader class.

The custom Tooltip itself  is a simple SkinnableComponent associated with a SparkSkin. There’s a required skin part for the text and a dynamic skin part for the label that only gets added if any value for a title  is provided.

For both title and text a RichText component is used within the skin so that formatting the text in a rich way is possible. The associated skin is then responsible to draw the tooltip based on the provided placement.
Having set this up, usage of the custom tooltips for any app is simple.

<s:Application               
    preloader="com.hulstkamp.flex.spark.preloaders.CustomMixinPreloader">
</s:Application>

This will register the custom ToolTipManager.

For additional documentation see the source in the demo (view source is enabled).

Since they’ve been built on beta sdks, these components might need some adjustments to work with the Flex 4 release sdk.

To save you the work of figuring out what to adjust here are the most requested components updated to Flex 4 release sdk. Click on the images, view source is enabled.

Flex 4 Spark Rating Component. View source enabled. Original post here.

Flex 4 Spark Icon Button based on a generic skin.View source enabled. Original post here.

Flex 4 Spark icon button. View source enabled.Original post here.

Flex 4 Spark custom checkbox. View source enabled. Original post here.

Flex 4 Spark custom knob button. View source enabled. Original post here.

In addition to this the flag useChromeColor can be set to tell the SparkSkin to use chromeColor for colorization. For custom skins this can be set by overriding initializationComplete() in the skin.

override protected function initializationComplete():void  {
 
	useChromeColor = true;
	super.initializationComplete();
}

Internally Flex checks this flag in updateDisplayList() of a SparkSkin and uses the value in chromeColor for colorization (respecting exclusions in get colorizeExclusions()).

If you are using Gumbo-Components from this blog that use baseColor be sure to make these adjustments.

• Show a placeholder-icon that reflects the current rating and serves as an interactive element to open the ratings
• ratings pop up for adjustment
• both the placeholder-icon and the ratings-icons will be gradually filled with color when adjustments are being made
• the icons are defined in FXG
• the icons are not defined in the skin but can be passed as a style for generic use (one skin for different icons and ratings)
• there is colorization of the icons based on styles
• smooth transitions when opening the ratings

Here’s a pseudo city-rating demo that shows variations of the component using different icons and color settings for different ratings.

You’ll find the source at the end of this post. It is fully documented but here’s an overview of the key-concept nonetheless.

Skin-Parts

There are skin-parts for the open-button (which is actually a group that works as a button), the drop-down which is a group that holds the entire pop-up, the active-group and the passive-group that hold the icons for adjustments of the rating and the label-element to show the rating as text.

Building the View

The icons are not part of the skin. They will be set at run time and are pushed down to the skin when the component loads the different skin-parts.

In partAdded() of the component, the active-group and the passive-group are filled with the icons. Five icons in a colorized version are pushed down to the active part.  Five default icons are pushed down to the passive-group.

Masking and Fill Effect

To create an effect that gives the impression of gradually filling the icons when the rating is adjusted, masks are used.  When skin-parts are loaded, the component applies a mask to the active-group.  When the mouse is dragged to adjust the rating, the width of the mask is updated and the (colorized) icons of the active-group are revealed.

The mask is not part of the skin. It is created at run-time by the component and applied to the relevant skin-part.

FXG Icons passed via Styles

The Icons are defined in FXG. Basically each Icon is a MXML-Component. The Icons are passed as a ClassReference to the component via styles. The ClassReference is then used to create an instance of this class at run-time. The instances of the icon are then added to their respective groups.
An Icon is basically a mxml-component that extends from Group. You can create your own and reference it via the rating Icon style.

Colorization based on Styles

The Icons are colorized at run-time. Based on some colors that are passed as styles the icons get colorized using a ColorTransform.

Effects on PopUp

There is a resize and a fade effect when the pop up is openend. These are defined on the skin - you can remove them by simply commenting out the transition part in the skin.

Separation of Concerns

Spark promotes a clean separation of concerns. The Component should keep track of the data/state and work as a controller, the skin is there for the view.  I decided to create and update the mask in the component, because the masking effect is an inherent part of this implementation and setting up the masking infrastructure in the component helps to keep the skin cleaner. Another approach would be to define the mask in the skin, then pull the value for the rating from the component and adjust the mask accordingly.
Still, every aspect of the look (gap, background-colors, borders, effects etc.) is controlled by the skin.

Usage

Setting the basic styles for the AHPopUpRatingComponent:

ah|AHPopUpRatingComponent {
	skinClass: ClassReference('AHPopUpRatingComponentSkin');
	passiveIconColor: "0x808080";
	activeIconColor: "0xc0c0c0";
	baseColor: "0xb0b0b0";
}

Using a variation of style values: For this example use styleName=’medicareRating’ on the component to set the css-class. It uses the Icon under myLibrary.HealthCross and has a light blue color for the active icons.

ah|AHPopUpRatingComponent.medicareRating {
	ratingIcon: ClassReference('myLibrary.HealthCross');
	activeIconColor: "0xCAEAFF";
}

The icons are mxml-components, that extend from Group. Use the fully qualified class-path in the ClassReference of the ratingIcon-style to reference the icon. Here’s an example:

<s:Group horizontalCenter="0" verticalCenter="0" width="25" height="25"  xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark">
	<s:Path  x="5" winding="nonZero" ai:knockout="0" data="M 9.404 0.01 C 9.051 8.355 -1.506 9.232 3.065 16.324 C 1.835 17.4 0.006 19.866 0.006 25.01 L 1.886 25.01 C 1.886 20.554 3.357 18.569 4.244 17.776 C 18.309 18.361 13.558 4.163 9.404 0.01 Z" >
		<s:fill>
			<s:LinearGradient x="6.82861" y="0.00683594" scaleX="25" rotation="90">
				<s:GradientEntry color="0xfbfbfb" ratio="0"/>
				<s:GradientEntry color="0xdcdcdc" ratio="0.5"/>
				<s:GradientEntry color="0xcccccc" ratio="0.5"/>
				<s:GradientEntry color="0x909090" ratio="1"/>
			</s:LinearGradient>
		</s:fill>
		<s:stroke>
			<s:SolidColorStroke color="0xd8d8d8" caps="none" weight="1" joints="miter" miterLimit="4"/>
		</s:stroke>
	</s:Path>
</s:Group>

Get the source (sdk: 7282) here.

Source updated to release sdk.

What I want is:

• work with FXG Graphic Elements for simpler manipulation and scaling
• easily export the FXG-Definitions for the icons from a tool and/or be able to change them in FB directly
• colorize the icons based on a color style-property and do this per state
• change the icons based on a style-property and do this per state
• change icons at runtime
• scaling effect on icon
• have ONE generic skin, so no duplicates for different icons are necessary

Most of the trouble with generic skins comes from the fact that there is no way to access the FXG Library-Definitions at run-time  (as far as I know) - like getting an instance of a symbol in the library, the way we had in flash. Here’s a hack but I’d rather not use it.

After some headaches I finally managed to get a solution I can live with:

Click here for a test.

You’ll find the source at the end of this post.

The solution regarding the work flow mainly comes down to

• Create Icons in Illustrator and convert them to symbols. One symbol per icon, name them. Save from Illustrator as ai.
• Load the Illustrator-File in Flash Catalyst and go to the Code-View
• You’ll see that FC creates mxml-files with the graphical content per icon
• Copy these files over to Flex-Builder or set the source path so that the catalyst export is in your flex project

In the code there are some key concepts:

• In the skin there is a group where the icons will get attached at run time
• The skin listens for state changes and creates an instance of an icon component based on the iconName that is passed via styles.
• There is some caching involved, so that there will be no instantiation when an icon/state has allready been created
• The Icons get colorized based on a style property and - if defined  - per state.
• The colorization occurs recursively, diving through the nested elements and setting the color of any nested FilledElement
• There is some code involved that manages the scaling of the new instances for the transitions
• Icons, colors and baseColors can be set via styles (and using pseudo selectors for over and down states)

Here’s the source (sdk 4.0.0.7282)

Source updated to Flex 4 release sdk.

Note: As a variation to instantiate the icons you could put all the FXG-Definition in the Skin inside the library and create them at runtime using the hack mentioned at the beginning of this post.

Out of the box there are basically three ways to get graphics into a Spark skin.

Use Image:

Use an Image component in the skin of the button and embed the icon into a style that is used by the button (Using a property and fetching the graphic from there is another variation).

.btnClass {
symbol: Embed(source='../assets/crossSymbols.swf', symbol='addCross');
}
...
<mx:Image id="symbol"  source="{hostComponent.getStyle('symbol')}" />
...
or
...
<s:BitmapImage  source="{hostComponent.getStyle('symbol')}" />

pros:

• Can use bitmaps or vectors
• When using vectors, scaling effects of the graphic works well
• possible loading of graphics at run time
• reusable skin for different graphics

cons:

• Overhead by using Halo Component in the skin
• No FXG defined graphics, if you want them.

Use Spark BitmapImage

Works the same way as above, but uses an BitmapImage in the skin:

pros:

• Can use bitmaps or vectors
• reusable skin for different graphics

cons:

• Vectors are internally drawn to a bitmap an treated accordingly
• Scaling effects work not so well since bitmaps are used
• No FXG defined graphics, if you want them.

Use FXG GraphicElements

The Graphics are defined by FXG Graphic Elements directly.

pros:

• Uses FXG (with possible bi-directional tooling support)

cons:

• Skins are not reusable for different graphics, graphic is ‘hardcoded’ into the skin

Personally, I’d love to use FXG. With Flash Catalyst, the FXG-Support in Illustrator et al. and the obvious commitment of Adobe to push FXG as the XML-based graphics interchange format for the Flash Platform, I guess it will be easier and more transparent to work with FXG when it comes to vector graphics. Exporting all the stuff to swfs or swcs is ok, but i’d rather not.

Now, creating a spark skin for every OK-, Submit- and Cancel IconButton etc. just won’t cut it. Sure you can copy the skin over but when you have lots of transitions and stuff and your client asks for a change you gonna have to repeatedly change the skins. Not very funny.

All that’s needed is a way to access the Library-definitions of FXG at runtime. Up until now, I haven’t found any, except for the hack I posted here.

After banging my head against a wall again and again, I’ve finally found another way I can live with.

Here’s an example of a Spark Icon Button done in Flex 4. There are smooth transitions on the background gradient between the up and over states. From the over state to the down state the shadows are removed smoothly. Each button has a different base color.

Click here for a demo.

Apart from the new skinning architecture there are a couple of aspects that make defining the look and feel of Spark Components easy:

• Transitions and effects that look up the values in the states
• Pseudo-Selectors for component-states, as well as id- and descendant selectors
• Enhanced states with group states.
• Colorization and exclusion

Transitions & effects

In this example the skin defines some transitions. There are AnimateColor effects that work on the gradient entries. There’s no special configuration involved, since the default-property that AnimateColor works on is… color . On the GradientEntry object there is a property for color. Flex automatically looks up the color values from the referenced states on the gradient entries.

In the states declarations there is an additional stateGroups ‘overStates‘ defined, that is referenced by the gradient entries.  So there’s no need to explicitly define the colors for every state.

<s:states>
  <s:State name="up" />
  <s:State name="over" stateGroups="overStates"/>
  <s:State name="down" stateGroups="overStates" />
  <s:State name="disabled" />
</s:states>
.
.
.
<s:Transition  fromState="up" toState="over" autoReverse="true" >
  <s:AnimateColor  targets="{[ge1, ge2, ge3, ge4]}"  duration="250" />
</s:Transition>
<s:Transition  fromState="over" toState="up" autoReverse="true" >
  <s:AnimateColor targets="{[ge1, ge2, ge3, ge4]}" duration="750" />
</s:Transition>
.
.
.
<s:fill>
  <s:LinearGradient x="32.019" y="0.5" scaleX="25.5708" rotation="90">
	<s:GradientEntry id="ge1" color="#c0c0c0" color.overStates="#ffffff" ratio="0"/>
	<s:GradientEntry id="ge2" color="#939393" color.overStates="#e3e3e3" ratio="0.5"/>
	<s:GradientEntry id="ge3" color="#7e7e7e" color.overStates="#cecece" ratio="0.5"/>
	<s:GradientEntry id="ge4" color="#6a6a6a" color.overStates="#bbbbbb" ratio="1"/>
  </s:LinearGradient>
</s:fill>

There are also Animate effects that work on the strength of the DropShadowFilters. The SimpleMotionPath entries tell the Animate effect to work on the strength property. Note that there are no values defined on the effects & properties of the transitions. Flex automatically looks up the start and target values from the referenced states.

<s:Transition  fromState="over" toState="down" autoReverse="true" >
   <s:Animate duration="150" targets="{[dsfBg, dsfSymbol]}" >
	<s:SimpleMotionPath  property="strength" />
  </s:Animate>
</s:Transition>
<s:Transition  fromState="down" toState="*" autoReverse="true" >
  <s:Animate duration="150" targets="{[dsfBg, dsfSymbol]}" >
	<s:SimpleMotionPath property="strength"  />
  </s:Animate>
</s:Transition>
.
.
.
<s:filters>
  <s:DropShadowFilter id="dsfBg" alpha="0.5" blurX="0" blurY="0" distance="1" strength="1" strength.down="0"  />
</s:filters>
.
.
.
<s:filters>
  <s:DropShadowFilter id="dsfSymbol" blurX="0" blurY="0" distance="1"  strength="1" strength.down="0"/>
</s:filters>

Now, the buttons have a subtle effect when the mouse is rolled over and pressed: The gradient colors get lighter and the Shadows disappear giving the impression that the button is pressed.

Styles. Pseudo-, Type-, Id- & Class-Selectors

We defined the gradients in grayscale. What when we want colored buttons? No need to change the gradients. Flex automatically colors the components based on the baseColor style. We can set the baseColor for each state using pseudo selectors.  Here’s an example of how to style the button that shows all of the selector types (id-, type- and class-selectors):

@namespace mx "library://ns.adobe.com/flex/halo";
@namespace s "library://ns.adobe.com/flex/spark";
 
/*   
 *	Using ID selectors with compund selectors (type and class selectors) 
 *	to define the appearance of the buttons 
 */
 
/* Define normal state styles on spark button type inside a desc container */
#desc s|Button {
	skinClass: ClassReference('AHSimpleIconButtonSkin');
	baseColor: "0x505050" ; /* Do not use black black; /*"0x56d9e5";*/
	color: #FFFFFF;
}
 
/* Define over states styles on spark button type inside a desc container */
#desc s|Button:over {
	baseColor: "0x97CD20";
}
 
/* Define down states styles on spark button type inside a desc container */
#desc s|Button:down {
	baseColor: "0xa0d828";
}
 
/* compound. override the over state of the button in element desc for class styleClass blueButton */
#desc .blueButton:over {
	baseColor: "0x56d9e5";
}
 
/* compound. override the down state of the button in element desc for class styleClass blueButton */
#desc .blueButton:down {
	baseColor: "0x56d9e5";
}
 
/* compound. override the over state of the button in element desc for class styleClass redButton */
#desc .redButton:over {
	baseColor: "0xd52A03";
}
 
/* compound. override the down state of the button in element desc for class styleClass redButton */
#desc .redButton:down {
	baseColor: "0xE53A13";
}
.
.
.
<s:HGroup id="desc" horizontalCenter="0" verticalCenter="0" verticalAlign="middle" gap="5">
	<s:Button  label="Green" 	useHandCursor="true" buttonMode="true" />
	<s:Button  label="Blue" 	useHandCursor="true" buttonMode="true" styleName="blueButton"/>
	<s:Button  label="Red" 		useHandCursor="true" buttonMode="true" styleName="redButton"/>
</s:HGroup>

Colorization & Exclusion

By setting the baseColors for different states, Flex will colorize the component accordingly.  A dark grey in the up-state, a color in the over state and a lighter color in the down state.

The bad thing is that everything gets colorized. The good thing is that you can overwrite a function on SparkSkin to exclude elements from being colorized. We only want the background gradient to get colorized, so lets exclude the other elements from colorization:

<fx:Script>
<![CDATA[         
	/* Define the skin elements that should not be colorized. 
	exclude symbol and text group */
	static private const exclusions:Array = ["symbol", "textGroup"];
 
	/** 
	 * @copy spark.skins.SparkSkin#colorizeExclusions
	 */		
	override public function get colorizeExclusions():Array {return exclusions;}
]]>        
</fx:Script>
.
.
.
<!-- The group with the symbol with a shadow applied to. In a group for colorization exclusion -->
<s:Group id="symbol" verticalCenter="0" left="7" top="9" right="7" bottom="7">
	<s:filters>
		<s:DropShadowFilter id="dsfSymbol" blurX="0" blurY="0" distance="1"  strength="1" strength.down="0"/>
	</s:filters>
	<s:Path winding="nonZero" data="M12.6924 0L5.76855 6.92383 2.30762 3.46191 0 5.76855 3.46191 9.23145 5.76855 11.5391 8.07617 9.23145 15 2.30762 12.6924 0Z" >
		<s:fill>
			<s:SolidColor color="#ffffff"/>
		</s:fill>
	</s:Path>
</s:Group>

There is a group with an id ’symbol’ that is referenced in the exclusion array. Do the same for the label element.

Here’s a test and here’s the source (sdk 4.0.0.7282)

Source updated to Flex 4 release sdk.

The solution is to use virtualization on the layout of the dataGroup. By setting useVirtualLayout=true, ItemRenderers are recycled, the performance will be fine even for 100′000 and more records (depending on complexity).

There are a couple of things to considerate:

• Since ItemRenderers are recycled you must take care of updating the components in your renderer to the correct state, so that they reflect the underlying data (i.e If the data states, that a player is a midfielder and you have a checkbox for this in your renderer, then make sure to set the state of this checkbox based on the underlying data, that is passed down). Also, the data object being pushed down from the Host-Component to the ItemRenderer could be null, so we have to check for this as well, preventing NPEs.
• Measurement will be approximate, either based on the first element, or a typical element you can reference or by setting rowHeight when using variableRowHeight=false.
• One drawback of virtualization is that when using the itemRendererFunction property, the renderers arent recycled. The function is expected to create an Instance (wrapped in a ClassFactory) of an appropriate renderer for the data-item being passed. I haven’t looked into this, but there could be a way of creating your own ItemRenderer pool and returning an suitable renderer from that pool.
• Checking the Profile, you’ll see that with virtualization the Renderers get reused, when virtualization is off, you’ll get as many Renderers as you have records.
• Another disadvantage is that virtualized layouts do not respect layout element’s includeInLayout property.
• In the Design Specification it is stated that “Virtual layouts with small numbers of items whose sizes vary dramatically will respond poorly to interactive thumb scrolling. Responsiveness will improve as the variation in size decreases and/or the length of the list increases”. In the test I did, I could not find any problems with poor responsiveness in scrolling, yet.

My findings are, that in practice the performance is very good on huge data sets when virtualization is used.  The drawbacks can be handled or are neglectable in many situation where thousands of rows must be used.

Here’s a simple test to check out virtualization and measurement when using increasing amounts of data.

VerticalLayout.variableRowHeight and HorizontalLayout.variableColumnWidth properties are set to true by default. This might affect performance in a bad way, since Flex has to determine the size of each child. Setting theses properties to false in conjunction with rowHeight / columnWidth or a typical element or the dimension of the first element can affect performance in a positive way.

DefaultItemRenderer that converts its data item to a single String for display in a Spark SimpleTextcontrol and the DefaultComplexItemRenderer that displays a component in a Group container. Each component is wrapped in its own Group container.

spark.components.supportClasses.ItemRenderer

• labelText String representation of the data-item.
• data The original data
• owner The Host-Component of the ItemRenderer. Can be used to fetch data.

A host-component that implements the IItemRendererOwner interface has methods where data is pushed down to the ItemRenderer

• itemToLabel() converts the data item to a String representation.
• updateRenderer()

One can overwrite these methods to manipulate data and the representation of the data.

Update: To be more precise (thanks to Steven Shongrunden@Adobe)

virtualization will be used even when an item renderer function is defined, but in that case item renderer recycling will not happen. Instead renderers will be created and destroyed roughly as they come in and out of view. (Compare this to the non-virtual case where every renderer is instantiated at startup). ItemRenderer recycling can be more performant than creation and destruction (depending on the renderers) so if you want to get the best performance it’s typically better to define an itemRenderer rather than an itemRendererFunction

The skin uses two additional properties (symbolColorChecked,  symbolColorUnchecked) for the color of the marks:

   s|CheckBox {
       skinClass: ClassReference("AHCheckboxSkin");
       symbolColorChecked: "0x70d000";
       symbolColorUnchecked: "0xe83800";
       fontSize: "11";
       color: "0x606060";
}

The skin goes like this:

.
.
.
 
	<fx:Script>
	<![CDATA[
		import mx.utils.ColorUtil;
		import mx.events.FlexEvent;
 
		[Bindable]	
		private var highlightColor:uint; 
 
		protected function sparkskin1_creationCompleteHandler(event:FlexEvent):void
		{
			hostComponent.buttonMode = true;
			hostComponent.useHandCursor = true;
			var col:uint = uint (hostComponent.getStyle('color'));
			highlightColor = ColorUtil.adjustBrightness(col, 80);
		}
	]]>
	</fx:Script>
 
 
	<fx:Declarations>
		<s:Linear id="easer" easeInFraction="0"  easeOutFraction="1" />
	</fx:Declarations>
 
	<s:states>
		<s:State name="up"  stateGroups="unchecked" />
		<s:State name="over" stateGroups="overStates, unchecked" />
		<s:State name="down" stateGroups="downStates, unchecked" />
		<s:State name="disabled" stateGroups="disabledStates, unchecked" />
		<s:State name="upAndSelected" stateGroups="selectedStates, checked" />
		<s:State name="overAndSelected" stateGroups="overStates, selectedStates, checked" />
		<s:State name="downAndSelected" stateGroups="downStates, selectedStates, checked" />
		<s:State name="disabledAndSelected" stateGroups="disabledStates, selectedStates, checked" />
	</s:states>
 
	<!-- Transitions for the mark -->
	<s:transitions>
		<s:Transition  fromState="over" toState="overAndSelected" >
			<s:Parallel target="{checkedMark}" >
				<s:Scale duration="250"  easer="{easer}" />
			</s:Parallel>
		</s:Transition>
		<s:Transition fromState="overAndSelected" toState="over" >
			<s:Parallel target="{uncheckedMark}">
				<s:Scale duration="250" easer="{easer}" />
			</s:Parallel>
		</s:Transition>
	</s:transitions>
 
	<!-- Label -->
	<s:SimpleText id="labelElement"
				  textAlign="start"
				  color.over="{highlightColor}"
				  color.down="{highlightColor}"
				  color.overAndSelected="{highlightColor}"
				  color.downAndSelected="{highlightColor}"
				  verticalAlign="middle"
				  lineBreak="explicit"
				  left="16" right="0" top="3" bottom="3" verticalCenter="2" />
	<!-- Group with the marks --> 
	<s:Group id="marks" verticalCenter="0" width="11" height="11" left="0" >
 
		<!-- GraphicElement for the checked-mark -->
		<s:Path horizontalCenter="0" verticalCenter="0" width="11" height="11" winding="nonZero" data="M 100 0 C 75.148 24.853 46.191 87.574 46.191 87.574 C 46.191 87.574 14.204 40.716 0 40.716 L 25.11 41.012 L 43.787 62.213 L 79.29 0 L 100 0 Z" 
				id="checkedMark" scaleX.unchecked="0" scaleX="1" scaleY.unchecked="0" scaleY="1">
			<s:fill>
				<s:SolidColor color="{hostComponent.getStyle('symbolColorChecked')}"/>
			</s:fill>
		</s:Path>
 
		<!-- GraphicElement for the unchecked-mark -->
		<s:Path horizontalCenter="0" verticalCenter="0" width="9" height="9" winding="nonZero" data="M 100 90.29 L 60.694 42.28 C 72.2 26.205 84.896 9.838 95.214 0 L 74.28 0.1 L 51.336 30.851 L 26.922 1.031 L 0 1.031 C 13.126 7.917 29.115 24.561 43.297 41.625 L 7.425 89.702 L 28.995 89.617 C 28.995 89.617 39.309 73.04 52.832 53.468 C 68.081 72.987 79.403 90.131 79.403 90.131 L 100 90.29 Z" 
				id="uncheckedMark" scaleX.checked="0" scaleX="1" scaleY.checked="0" scaleY="1">
			<s:fill>
				<s:SolidColor id="checkMarkFill" color="{hostComponent.getStyle('symbolColorUnchecked')}"/>
			</s:fill>
		</s:Path>
 
		<!-- Fake HitArea. TODO: Sort out how to use hitArea property, which does not seem to work correctly yet, but haven't investigated -->
		<s:Group width="100%" height="100%" alpha="0" >
			<s:Rect width="100%" height="100%"  >
				<s:fill>
					<s:SolidColor color="0xff0000" />
				</s:fill>
			</s:Rect>
		</s:Group>
 
		<s:filters>
			<s:DropShadowFilter distance="1" strength="0.75" blurX="1" blurY="1" />
		</s:filters>
	</s:Group>
.
.
.

FXG GraphicElements are used to draw the marks. The color of the marks are fetched from the hostComponents styles. The customs styles are set in the style definition of the CheckBox. When creation is complete some flags are set, so that the hand-cursor is shown when rolling over the label-field. An highlight-color for the label is calculated from the color-style-property and used in the over- and down-states. Transitions are use to have a scale-effect when the CheckBox is un(selected).

Test & source (sdk 4.0.0.7282) .

Source updated to Flex 4 release sdk.