Monthly Archives: July, 2007

Just Came From Flex Camp in SF

I had a late night at Flex Camp at the Adobe San Francisco office last night. Some of us on the Flex team were the last remaining stragglers hanging out in the Flex/AIR room until facilities asked us to leave. Anyways, the picture above is from some of the cool schwag that we got out of the night. They had beer mugs, t-shirt (with actual ladies sizes), a Flex yo-yo, a canvas bag and a free copy of Flex Builder. Wow, that was a big give away of hundreds of dollars!

Anyways, although I mostly hung out in the Flex room fielding some questions (only half of which I could answer), I did see a few cool demos. By the way, I was one of the few people wearing the “got bugs?” t-shirts promoting our public bugbase at http://bugs.adobe.com/flex (another plug).

One of the things that I really liked seeing was the demo from Mix Book. They are a web 2.0 start-up allowing you to share and create books with your friends. And, yes…there are a lot of companies where you can create photo books, but, as far as I know… there are none where you can have your friends make contributions to the same book. Anyways, I registered myself an account last night and maybe I’ll make up a book soon.

In the Flex room, we were talking to people about our open source process and trying to motivate people to log bugs as well as some tips on “How To Get Your Bugs Fixed”. Here were some of the tips we gave people:

How To Get Your Flex Bugs Fixed 1. Narrow down your use case.

2. Include a test file to reproduce the bug. Include the mxml and AS files (not just the swf).

3. Vote on bugs! Vote! Vote! Vote! Bugs don’t actually go to the Flex Dev team until they have a couple of votes (I think the magic number is two).

4. Categorize your bug correctly.

5. Check back on the status of your bug. Sometimes we comment in them asking for more information.

6. Add screenshots. Its easier to reproduce a bug and see the severity of a problem with a screenshot.

7. State the severity of a bug. If this is blocking your work and there is no workaround, specify this in the comments. Also, if the bug is a regression, be sure to mention that the use case worked in 2.0 or 2.0.1 and not in the newer build that you are working on. We upgrade these bugs right away.

8. Alcohol and snacks for the Flex QA team never hurt anyone’s chances of getting bugs fixed 🙂

By the way, the best source for current information regarding our open source initiatives are at: https://bugs.adobe.com/confluence/display/ADOBE/Home
Unfortunately, we haven’t put together one location for all of our info yet. But, this is on the agenda and it will eventually live somewhere on: http://opensource.adobe.com/

Bug: Workaround For SortField bug in DataGrid

Several people have run into this bug (SDK-9398) where the SortField that you set for one of your DataGrid columns get clobbered after the user sorts a different column. In current builds of Flex, the DataGrid code re-sets the fields array on the Sort object to the SortField in current “play” clearing any other SortFields previously set on the collection. It doesn’t look like the bug is going to get fixed any time soon, so I was tasked with finding a workaround today.

You can see the problem in this example by sorting the various columns. After sorting the ‘birthday’ column in this example, the ‘name’ column loses its SortField which specified that its sorting should be case sensitive:

Demo of Bug: originalSortBug.swf

Source of Bug File: originalSortBug.mxml

I found a workaround for the bug where you reset the SortField every time a user clicks on the a DataGridColumn header. So, in my workaround, I listen for the headerRelease event and reset the SortField at this time. Here is an example that uses the workaround:

Demo of Workaround: sortingBug.swf

Source for Workaround: sortingBug.mxml

Upcoming Changes to Flex Styles (codename:Moxie)

In the last three weeks or so, I’ve been testing the feature work of Jason Szeto who changed the way the styles for many components get passed on to their subcomponents. This “StyleProxy” feature for Flex makes the framework more explicit regarding the styles that are passed through from a component to its subcomponents. Subcomponents used to get all of its styles from its parent component. For example, if you set a style like cornerRadius on a DateChooser, this style was inherited by the nextMonth and prevMonth buttons. This was probably not your intention. You probably only wanted the cornerRadius to affect the DateChooser itself. Just to be clear what some of the “subcomponents” of Components are, here are a few brief examples:

Component Sub-Components
DateField TextField, Button (with calendar icon), DateChooser
MenuBar Sub-menus
Accordion Accordion Headers
NumericStepper TextField, up button, down button
ColorPicker swatch panel

With the changes with this StyleProxy feature, you will be able to explicitly set the styles of these sub-components. Some of the components now have a style filter that specifies which non-inheriting styles will be passed from the parent component to its sub-component. (Inheriting styles have not changed). Here is an example of a style filter in DateChooser:

protected function get nextMonthStyleFilters():Object
{
return _nextMonthStyleFilters;
}private static var _nextMonthStyleFilters:Object =
{
“highlightAlphas” : “highlightAlphas”,
“nextMonthUpSkin” : “nextMonthUpSkin”,
“nextMonthOverSkin” : “nextMonthOverSkin”,
“nextMonthDownSkin” : “nextMonthDownSkin”,
“nextMonthDisabledSkin” : “nextMonthDisabledSkin”,
“nextMonthSkin” : “nextMonthSkin”,
“repeatDelay” : “repeatDelay”,
“repeatInterval” : “repeatInterval”
};

The _nextMonthStyleFilters object specifies the non-inheriting styles that will be passed onto the nextMonth button in a DateChooser. If you want to change what styles get passed to the nextMonth button, you would subclass DateChooser and override this nextMonthStyleFilters getter.

Other components like MenuBar do not use this concept of a style filter, however, the way they handle non-inheriting styles has changed. The sub-menus of a MenuBar will no longer get non-inheriting styles like backgroundColor from its parent MenuBar. Instead, you would need to specify backgroundColor in the “menuStyleName”. In Flex 2.0.1, this will work:

<mx:MenuBar backgroundColor=”0xFF0000″ dataProvider=”{someData}” />

However, in future versions of Flex (codename:Moxie), the backgroundColor set on MenuBar won’t affect the sub-menus. To have the backgroundColor affect the sub-menu, you need to use the menuStyleName style. Here is an example:

<mx:Style>
.myStyle {
backgroundColor: #FF0000;
}
</mx:Style>

<mx:MenuBar menuStyleName=”myStyle” dataProvider=”{someData}” />

Here is a list of Components that are changing:

Component/Container Change to Styles
Accordion The Accordion headers don’t get non-inherited styles like fillColors from the Accordion. Instead, use headerStyleName.
ColorPicker The swatch panel does not get non-inherited styles like columnCount, textFieldWidth, horizontalGap etc. from the ColorPicker anymore. Instead, these styles should be set using the swatchPanelStyleName.
ComboBox The dropdown does not get non-inherited styles set from the ComboBox. Instead, use dropdownStyleName.
DateChooser The nextMonth, prevMonth, nextYear, prevYear buttons and the calendar layout don’t get all of its styles from DateChooser anymore. To use different styles, subclass DateChooser and change the style filters.
DateField The DateChooser pop-up doesn’t get non-inheriting styles from the DateField anymore. Use the dateChooserStyleName instead.
LinkBar The LinkButtons don’t get non-inheriting styles from the LinkBar. Use linkButtonStyleName.
MenuBar The sub-menus no longer get non-inheriting styles like backgroundColor and backgroundAlpha from MenuBar. Use the menuStyleName instead.
NumericStepper Some styles are no longer passed from the NumericStepper to the up button, down button and/or TextField (some examples include borderColor). BorderColor no longer affects the buttons. To change the inherited styles subclass NumericStepper and change the style filters.
TabNavigator Tabs no longer get non-inherited styles from TabNavigator. Instead, use the ‘tabStyleName’.
All PopUps PopUps used to get styles from the parentApplication. PopUps will get styles from their ‘owner’

If you are compiling your Application in the newest version of Flex and you don’t want to have to update your application, you can get the old behavior by compiling your app with the -compatibility-version=2.0.1 argument.

These changes to style behaviors are available for your testing if you want to download a Flex SDK Nightly Build. The check-ins for these changes start at build 174443 and end around changelist 177145.

Using a headerRenderer for an Accordion

Keeping on the subject of customizing the Accordion header, I was thinking that it would be nice to be able to change the appearance of a header that was selected. Out of the box, flex offers the style selectedFillColors so you can change the background colors of your header when its selected. This is nice, but, it doesn’t seem like enough. I wish it had a selectedHeaderStyleName or something like that.

To make a few minor changes to the header when its selected, I’m going to use the headerRender. I’ve never done much testing of the Accordion component, so, its all fairly new to me. I assumed the headerRender was similar to a List itemRenderer and that I could pretty much put anything in there and it would just work. That isn’t the case. Your custom headerRenderer pretty much needs to extend Button, otherwise, you’ll need to build in way too much logic on your own. So, here is my sample that changes the fontSize and color of a selected header. It also changes the paddingLeft of all the headers because I didn’t like the default.

Demo: AccordionSample.swf

Sample Code: AccordionSample.mxml, MyCustomHeader.as

And if you want to change up the icons for various states of your Accordion, then, try Rich Tretola’s Accordion With Icons component. It’s pretty cool and he’s got ASDocs for it as well.

Customizing Accordion Headers for 2.0.1 and Moxie

Settingstyles like the fillColors, fonts and highlight colors on an Accordion header is pretty simple. However, I wanted to comment on the best practice for Flex 2.0.1 that will also work in the future release of Flex. In Flex 2.0.1, you can set many styles that affect the Accordion headers on the Accordion itself rather than using the headerStyleName style. So, you could do something like this:

<mx:Accordion color=”0xFF0000″ fillColors=”[0xCCDD66, 0x44FFFF]” icon=”infoIcon”>

In Flex 2.0.1, this code would work and the styles would get inherited from the Accordion to its headers. However, in Moxie (future release of Flex), this won’t work. Styles have been cleaned up and therefore, only styles set on the headerStyleName will affect the Accordion header. This is one of the areas that I’ve been working on testing the past few weeks. Styles on the Accordion that affected only the headers will be deprecated. This change is available as of Flex build 175091 which you can get from the Adobe Labs nightly build pages.

So, if you want the Accordion in your Application to work in future builds, set all of your Accordion header styles using the headerStyleName. Here is a screenshot of the demo that I’ve provided (excuse my developer art):

Accordion example

Demo: AccordionSample.swf

Sample Code: AccordionSample.mxml, QuestionIcon.gif

In this example, the icon, fillColors, highlightColors, fontFamily, color and selectedFillColors are all set within the headerStyleName.

Change DataGrid cell background with an itemRenderer

This is one of the most common questions that I’ve seen in various forums with regards to itemRenderers…. “How do I change the background color of my DataGrid cell depending on my data?“. As usual, the answer is to use a custom itemRenderer. In the following example, I am using the same itemRenderer for 2 of the 3 columns in the DataGrid. The itemRenderer checks if the data displayed in the cell is over the value 15, if so, it turns the background RED.

Demo: datagrid_reusable_itemrenderer.swf

Sample Code: datagrid_reusable_itemrenderer.mxml, BackgroundComp.as, airlines.xml

By default, a DataGridItemRenderer does not have a background fill. Therefore, there isn’t a simple style to set on a renderer to make the background some color. Instead, we need to draw our own fill for the renderer in a custom updateDisplayList function. In our renderer, we use this code:

override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
super.updateDisplayList(unscaledWidth, unscaledHeight);var g:Graphics = graphics;
g.clear();
var grid1:DataGrid = DataGrid(DataGridListData(listData).owner);
if (grid1.isItemSelected(data) || grid1.isItemHighlighted(data))
return;
if (data[DataGridListData(listData).dataField] > 15)
{
g.beginFill(0xCC0033);
g.drawRect(0, 0, unscaledWidth, unscaledHeight);
g.endFill();
}
}

Nested Inline ItemRenderers – A List in a DataGrid

This is just a fun example of using drop-in inline itemRenderers. Inline itemRenderers are when you use the <mx:Component> tag to define an itemRenderer within your mxml. In this example, I am using a DataGrid with two columns. The second column uses a List itemRenderer. The List uses an Image itemRenderer. Here’s a screenshot:

Demo: datagrid_cellrenderer_nested.swf
Code Sample: datagrid_cellrenderer_nested.mxml

In this example, the DataGrid is populated by an Array with objects that looks like this: { price: “under $50”, items: under50}. The value of the ‘items’ property is actually an array that is the dataProvider to the List. (You can also have the dataProvider to the List be a different filtered view collection of the DataGrid’s original dataProvider, but, I didn’t take the time to do that.)

Also, we did not specify the source of the Image itemRenderer. Because the ‘source’ property is the default property of an Image, the source is populated by default from the List’s dataProvider.

Good luck! There is so much we can do with itemRenderers.

News: Flex Camp … it’s Free!

Adobe San Francisco is hosting Flex Camp on Friday, July 27, 2007. Food and drinks will be provided and many of the Flex and Apollo engineers will be on hand giving talks or just answering questions. And… its all free. Beginners and advanced Flex developers are definitely welcome. Here is the info:

Friday, July 27, 2007

5:00 pm PT – 11:30 pm PT

601 Townsend St. San Francisco, CA

To register go to: http://flexcamp.eventbrite.com/