Sometimes it’s the simple things that make us happy. And for me one of those simple things is just how easy it is to make a <s:Button> look like an HTML link with Flex 4.

If you’re an HTML coder then first, “WTF you doin’ on my blog hillbilly boy?” and second you’re probably thinking, “Yeah, or you could just use HTML in the first place and actually have regular links. That may be true but can your regular links do this?

I’m laughing at the superior web standard. ( from??? ) And if you can do that with your shitty Javascript then can you do it in just 5 minutes – on all browsers? ‘Cause that’s all it took me and I’m being generous.

Watch the music-video tutorial

Show me some skin
Here’s all that you need in your HTMLBtn skin file. I said it was easy. Was I right or was I right? :)

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo">

<fx:Style>
@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/halo";

	.upStyle { color: #0000FF; }
	.overStyle { color: #009900; }
	.downStyle { color: #00FF00; }
	.disabledStyle { color: #666666; }

</fx:Style>

<s:states>
	<s:State name="up" />
	<s:State name="over" />
	<s:State name="down" />
	<s:State name="disabled" />
</s:states>

<s:transitions>
	<s:Transition toState="over" autoReverse="true">
		<s:Resize target="{ underlineOver }" />
	</s:Transition>

	<s:Transition toState="up" autoReverse="true">
		<s:Resize target="{ underlineOver }" />
	</s:Transition>
</s:transitions>

<s:Label
	id="labelDisplay"
	styleName.up="upStyle"
	styleName.over="overStyle"
	styleName.down="downStyle"
	styleName.disabled="disabledStyle"/>

<!--This is the blue line that is always present-->
<s:Rect
	width="100%" height="1"
	bottom="0" horizontalCenter="0">
	<s:fill>
		<s:SolidColor color="#0000FF"/>
	</s:fill>
</s:Rect>

<!--This is the green underline that grows out to 100%
width when the mouse moves over and then shrinks
back to 0 width when the mouse moves out.-->
<s:Rect id="underlineOver"
	width.over="100%" width.up="0" height="1"
	bottom="0" horizontalCenter="0">
	<s:fill>
		<s:SolidColor color="#009900"/>
	</s:fill>
</s:Rect>

</s:Skin>

Notice that the <Resize> Transitions only specify a target. You don’t have to bother with telling it exactly what width to transition to. It figures that out from the properties of the target. In this case it’s the <Rect> which has width.up=”0″ and width.over=”100%”. Have I said lately that I love Flex 4 states?

If you are dynamically instantiating custom components in Flex 4 you may have run into a strange runtime error:

ArgumentError: Undefined state ‘closed’.
at mx.core::UIComponent/getState()
…

You’re state name may be different but it’s still caused by the same issue. Basically you have no skinClass assigned to your component. So your component has no idea what to do with it’s current state. It’s no problem if you declare the component in MXML because there you can assign the skinClass. But if you are creating it dynamically you would think something like the following might work:

var myComponent:CustomComponent = new CustomComponent();
myComponent.skinClass = 'skins.CustomComponentSkin';

But you cannot do that. The only way that I know of to assign the skin is via CSS like this:

comps|CustomComponent {
	skinClass:  ClassReference( 'skins.CustomComponentSkin' );
}

That is a Type selector and so will work but only in the Application root. If you try that from inside another component then you’ll see a warning: CSS type selectors are not supported in components: ‘whateverComponentYouAreIn’.

You will have to take the above CSS and place it in the <s:Application> or in a CSS file that is declared in the <s:Application>

Upon further review
After doing a little research I’ve discovered that this is nothing new. The same situation applied in the MX days. I think I only noticed this problem recently because I always placed my CSS in a file declared in the <mx:Application>. However with a custom component it just seems natural to declare it’s CSS in the hostComponent. But I guess we’ll have none of that.

The only problem I find with this is what If I want to use different skins in different parts of my application? If anyone has a suggestion as to how to make that happen for dynamically created components then please comment.

First off, kudos to the Flex Builder team for creating a remarkable framework. You guys/gals rock! 99.9 % of the time.

<rant>

With that being said, what the frak were you thinking about when you named the styles for the font colors on <Button> states? You started out good with the Embed skin names:  upSkin, overSkin, pressSkin, disabledSkin. No problems there. All very self descriptive. Thank you.

However, to change the text color on a button for those 4 states is a bit tricky. First there’s color. That’s just the default color of the text in the up-state. The style name is a bit ambiguous don’t you think? Perhaps textColorUp would be more appropriate.

I don’t change the text colors for the hover and press states all the time so it’s easy to forget what they are. When I do look for them I look for, naturally, over and press text colors. But there aren’t any. This time the style names are perfectly descriptive textRollOverColor and textSelectedColor. The problem is that the skins are named by overSkin and pressSkin, respectively. One or the other would be just fine. I’d vote for textOverColor and textPressColor.

Besides, if I didn’t know any better I’d think that textSelectedColor was the color of the text when it is selected with the mouse.

Then we get to the last state: disabled. Or if you are more politically correct then call it the mousePressChallenged state. :) The style for this state is disabledColor. Which again begs the question: the color of what part of the button in the disabled state?

When I name properties I try to keep things grouped so that they all show up together in the code hinting and also so that if you find one of them you’ll know the other 3. I would name the styles as such:

• textColorUp
• textColorOver
• textColorPressed
• textColorDisabled

Then all anyone would have to do is type textC… and get the code hinting for all of the textColor states.

</rant>

At least now that I’ve bothered to blog about this I’m more likely to remember the cryptic styles names in the future. But then hopefully the style names will change in Gumbo and I won’t have to burden my feeble brain with these details.

Many of my clients have designers that give me assets for the Flex/AIR apps that I’m creating for them. I’m very happy when I get PNG files that are perfectly exported from Photoshop and ready to drop into the assets folder. Unfortunately I’m rarely happy. :( I get all sorts of things: jpgs, unorganized PSDs, you name it. And don’t get me started about file naming conventions.

The most common asset that gets skinned and then reskinned over and over are buttons. So I’m going to cover how I would like to get my assets. I’m sure many Flex developers will have similar workflows.

Button States
Buttons in the Flex framework have 4 states: upSkin, overSkin, downSkin, and disabledSkin. There are three main ways to skin a button – or most any component: using bitmap assets, CSS, or programatically. The majority of cases can be handled with a combination of the first two: bitmaps and CSS.

The example to the right displays the basics of creating skins for a Button. I have graphical assets as the backgrounds for the various states and then the text is generated in the code. You have no idea how much of a time saver that is. If you create assets for Flex do not put the text on them. You know why right: because that label will eventfully change which requires editing a PSD file, exporting, emailing, downloading, etc. A good 5-10 minutes for just changing the label of a simple button that could have been done in 5-10 seconds if it were done in code. And it’s the numerous changes like these that take just a few minutes that pile up over the course of a project to drive it well beyond the quoted time.

If you change the button label in the example you’ll notice that it grows horizontally as much as you need without distorting the corners. That’s 9-slice at work and it’s very handy. But the design has to work if the center of the button assets is stretched horizontally. If you added details you’ll have problems with the appearance. In that case it might be a job for a programatic skinning and that takes time.

If I’m designing a Flex app I’m almost certainly going to do it entirely with CSS and no bitmaps. That’s because I start by modifying the CSS to get the look that I want. But if a designer gives me even a simple button, like the example here, it could take a good hour or so of tweaking to get it almost identical. So it’s more time effective to just use bitmaps. And if the design changes then all I have to do is replace a bitmap instead of trying to figure out the exact changes to make to the CSS.

If you’re a designer and you want to style a component without bitmaps then go to the FlexCSS explorer and play around with the look you want and then send the exact CSS declaration to the developer you’re working with. That will make them very, very happy.

Naming Conventions
I find it best if the file name of the asset starts with a description of the style followed by the state. Bonus points if it includes the type of component it applies to. The assets for the example are: basic_btn_up.png, basic_btn_over.png, basic_btn_press.png and basic_btn_dis.png which is stylename_component_state.png.

Photoshop organization
There are two kinds of designers in the world: those who organize their PSDs and those who don’t. :)

The PSD that I used to create the assets for the example is available to download. It isn’t perfect but here are a few things that make working with PSDs much easier:

• The button states stack up on top of each other. That makes it easier for me to export and it makes it easier for you to get an idea what the change of states will look like since you can just toggle a folders visibility off/on to see the change.
• The PSD is cropped to the exact size that is needed for export. I don’t need to go in and select a part of the image and copy it to another PSD before saving for web.
• The button labels are in there so I can select the text layers and get the font colors right out of Photoshop.
• The 9-slice rectangle has been drawn which makes it very easy for me to make a few quick measurements and then add that to the CSS.

Can you think of anything else that makes the designer/developer workflow go smoother?

In this explorer I’m going to highlight everything I can think of that can be done to a TextArea. Most of the solutions – such as changing the lineHeight – comes from other developers. I’m just collecting everything I’ve found here as a central resource.

Here is the MXML code declaring the TextArea I’ll be talking about throughout the rest of this post – notice the ID=’ta’ for reference.

ValidateNow!
To access TextArea properties, such as lineHeight, textHeight, etc., you’ll want to call ta.validateNow(); before hand – thanks @brandon_ellis for the tip. That runs the Layout Manager which validates everything. Then the values should be correct. I’ve run into numerous problems trying to get the textHeight, especially when using htmlText. It always seems to be wrong unless calling validateNow();

Accessing the unaccessible
When creating a TextArea with MXML you can access the leading and fontSize properties. But accessing ta.leading or ta.fontSize in Actionscript won’t work. A simple work around – hack – is to set the values to Bindable variables and then change those varables as needed.

Addendum: Nick Kwiatkowski points out in the comments that fontSize and leading are styles – which is pretty obvious when you stop and think about it for a second – and that’s why they aren’t accessible to Actionscript unless you use ta.setStyle( ‘fontSize’, value ); Thanks Nick.

The term leading is so preMil
Leading is just the line height of the TextArea. Why they don’t just call it lineHeight I have no idea. So what if Photoshop calls it leading – which is probably a hold over from Gutenberg or something. I’m a programmer. Not a type setter!

Anyhow, if you want to get the current leading value of TextArea you’ll need to do a little dirty work. Turns out that you can’t just ask. But if you look at the ta.htmlText you’ll see the markup code in there complete with the leading value. It would look something like this:

I wrote this simple getter to suck the value out of there:

I could probably just assume that the position of LEADING in the htmlText will never change but what the hell. It easy enough to get the indexOf so that I know for sure I’m looking in the correct place. And besides, if the value goes into double-digits then I’ll have to look at a different substring.

All the above does is look for where the letters ‘leading‘ start. Then add 9 – number of characters in leading=”,  find where the next indexOf a double-quote starts from that point which will probably be either one or two characters away. ( If you have a value of leading with triple digits then you’re doing something wrong or trying to get into the Guinness book.

Addendum in the comments mrm suggests using regular expressions to find the leading value. Something like:

1 2	var match:Array = ta.htmlText.match(/&lt;TEXTFORMAT[^&gt;&lt;]+LEADING="(\d+)"[^&gt;&lt;]*&gt;/i); var defaultLeading:int = match[1];<!--formatted-->

Number of lines
Why, why, why would the number of lines be internal? I’m sure it’s Deepas fault. :-) So to get the number of lines in your TextArea try this:

}

To be fair the Flex Dev team is on average about 50 times smarter than me so maybe there is a good reason for numLines being internal.

What is like leading but different?
Try lineHeight. Leading is . . . um . . . you know, I’m not exactly sure what leading measures. But lineHeight is the height of a line in pixels. And of course you can’t just get it directly from the TextArea. You have to jump through yet another hoop – abet a small one.

Just how big is this thing?
Finally, if you need to know the pixel size of all of the text in the TextArea then just ask for ta.textHeight. Of course don’t forget to call ta.validateNow(); first or you’ll get a number that only resembles the textHeight.

Selecting Text
Programatically selecting text in a TextArea is simple. The problem is that unless the TextArea has focus you won’t be able to see what is selected. The trick is to give the TextArea focus after every change of the selection you make. That’s what I’m doing with the NumericSteppers that change the selectionBeginIndex and selectionEndIndex values.

Credits
I pulled all these examples from previous projects that I’ve worked on. But most of this I originally got from scowering other blogs – mostly blog.FlexExamples.com – so thanks everyone.