Blog

Gent pinged me on AIM.

“How do I get a ComboBox prompt?”

“Use the ComboBox prompt property.”

“Yeah, but it leaves once you select an item.”

“Put the prompt as the first item in the dataProvider.”

“Can’t do that for this context.”

“Make a custom list that has a prompt above it, and replace ComboBox’ dropdown with your new list.”

“I can’t, I’m about to go pimpin’ on a Friday night, and your not, so code it, sucka!”

“Pssff, you wish you had this grill. Fine…”

So, I attempted to do so in 2 hours, and gave up. Here are my results. Basically, you put a Label above the List. You then extend ComboBox to override the drop down factory so it uses your List instead. The only uncool part is you have to extend ListBase; kind of frustrating when I’m implementing all those interfaces, only to be forced into an inheritance tree… bleh! Extending ComboBox is a pain in the neck because everything is private; frustrating. Anyway, definitely not production code, but should get you started.

After talking to her majesty, there is actually a usability issue with drop downs on web pages in that, once you select an item, you can no longer “de-select” an item by selecting the prompt again if one doesn’t exist. Therefore, I stick to my original suggestion; throw the prompt item in the dataProvider instead.

Permanent ComboBox Prompt – View Source | ZIP

I had 2 days with the help of another developer to re-skin an existing Flex 2 app recently. It was nice to put a lot of my Flex 2 CSS practices to the test. What worked, and what didn’t?

What Didn’t

It was really hard to get multiple developers working on re-skinning. Every time I’d find a task, I could do it faster in the time it’d take me to articulate the requirements and/or send an email. Furthermore, most of the styles & image skins were defined in the CSS. While I do pride myself on having a pimp diff tool, it’s still a pain in the neck to “discuss” the CSS style changes with another developer during the diffing. I had a non-negotiable 2 day deadline. The last thing I want to do is discuss the theory behind borderStyle: solid over IM when I could be working.

Styles that were custom, such as .musicPlayerTitle, weren’t always that specific. Sometimes, title specific styles (stuff for text) were re-used by things that had nothing to do with a music player. While it’s nice to have re-use, this was confusing, and sometimes editing a style would adversely affect something you had no clue on; aka, spaghetti code, meet spaghetti styles. The real code wasn’t spaghetti styles; we quickly fixed the 2 I found.

Not everything was done in CSS. This was the worst offender, and I didn’t have time to clean it up. Thankfully, I was sequestered in my own branch of CVS, so no one (except my trusty co-worker) could see the nastiness. There were just a few, but enough to tick me off. Some controls had styles applied on their controls. Some had images in line in code that should of been put in the CSS. So, instead of re-skinning, I spent some time re-factoring & basically cleaning up stuff to at least be remotely consistent. My guess is, these were done to solve layout problems, and later weren’t ported to CSS. One in particular I created, which means I was lazy, and didn’t re-factor it into styles. Oops, I’m fired.

No control styles. The main thing I espouse is to style the component class vs. making a style, and applying it to an instance. While there were a few MX components done this way, there were no custom written components done this way. Therefore, I had to hunt down the View in question, where it was used, and find the style name, then go back to the CSS to change it. Pain in the neck.

Design View. Still worthless. Good to “dig down” to the control I need via double-clicking, but useless as a designer via styling/skinning.

What Did

There was a lot of CSS. This bode well, meaning the original developers (me included for part of it), had pretty much adopted the standard of all styling information goes in CSS. Except for 3 minor controls/screens, this went well. I could pretty much ensure the separate CSS file I created (a copy of the original) could remain as the top left tab in Eclipse all day as I changed styles.

Most styles did stay true to their name. Even if both used the same 4 styles with the exact same values, they still were applicable to their control. While the CSS became really big because of this, it couldn’t be helped frankly because the design didn’t really have a lot of UI re-use. Consistent naming went far in making this a straight forward process to update. There is no point in creating a custom, re-usable control if you are only going to re-use it once. Instead, we just had a lot of styles applied to the same MX List control. Designer’s fault, not ours.

A side benefit of having custom styles was that, on the 2nd day, I was able to start getting help from another developer. There were a lot of dialogues that a lot were styled via CSS. Since those styles were custom, it wasn’t that painful to merge since they were way at the bottom of the CSS file. We just announced it over IM, and I’d spent 2 minutes updating and merging.

Conclusions

I have a new respect for custom styles. I used to bash them, but now understand if the designer doesn’t give you a design that makes good use of re-use, you have no choice and this is the best way to do things cleanly. Regardless, the lack of component skinned styles was unacceptable , and I added a few. Flex 2 does a good job with a style inheritance, so you can be sure anything you use in your component will adopt the main styles. In the end, this greatly reduces the size of your CSS file, allows you to make application wide style / skin changes from just one file quickly, and allows those not familiar with Flex GUI to change the CSS.

Definitions

Override style:

Application
{
        color: 0x333333;
        background-color: 0xFFFFFF;
}

Component style:

MyComponent
{
        text-decoration: underline;
        color: 0x0000FF;
}

Custom style:

.mainLabel
{
        font-weight: "bold";
        font-family: "Verdana";
        font-size: 16px;
}