I have been immersed in Flex 4 lately and had this issue come up.  It seems like it might be fairly easy to run into and isn’t entirely obvious at first so I’ll share.  I had a custom component that included buttons that weren’t registering click events.

Here’s the scenario.  I created a custom component that contained a background rectangle for highlighting, a label to display the name of the item, a toggle button for expanding the item and a button for editing the item.  I won’t get into the specifics of what this component is for, but just stick to the high level concept.

[ [expandBtn:ToggleButton] [labelDisplay:Label] [editBtn:Button] ]

The component had a number of states:

[SkinState("up")]
[SkinState("over")]
[SkinState("down")]
[SkinState("upAndSelected")]
[SkinState("overAndSelected")]
[SkinState("downAndSelected")]

This is similar to the ToggleButton component in the SDK but didn’t need the disabled state.  I created mouseEvent handlers to take the rollOver, rollOut, mouseDown, mouseUp and click events so I could handle them appropriately, setting properties for the getCurrentSkinState() method to use and setting invalidateSkinState() after changing the properties.

In the components up state, I wanted just the label to show and then when the user hovers over the component, the expand and edit buttons show.  Using states, this is simple enough to accomplish in the skin for the component:

<s:states>
  <s:State name="up" />
  <s:State name="over" stateGroups="overStates" />
  <s:State name="down" stateGroups="downStates" />
  <s:State name="upAndSelected" stateGroups="selectedStates" />
  <s:State name="overAndSelected" stateGroups="overStates, selectedStates" />
  <s:State name="downAndSelected" stateGroups="downStates, selectedStates" />
</s:states>
...
<s:ToggleButton id="expandBtn" includeIn="overStates" .../>

<s:Label id="labelDisplay" ... />

<s:Button id="editBtn" includeIn="overStates" .../>

The ellipses indicate additional code that is irrelevant.

I added the click handlers for the buttons in the custom component so I could capture the clicks and dispatch my own custom event.

So this starts out looking fine.  The buttons show up when the mouse is hovered.  Great.  I click on the edit button and… nothing.  The click handler is never called.  Do you see why?

Hint: Because events like clicks travel the displayList, the surrounding component will react to the clicks of the buttons inside it too.

Ok, here’s the chain of events:

1. The user presses the mouse button down over the edit button.
2. The edit button gets the mouseDown and enters it’s down state (if it has one).
3. The surrounding component gets the mouseDown and changes it’s skin state to the down state.
4. The edit button is not included in the down state, so it is removed.
5. The user releases the mouse button.
6. The surrounding component gets the mouseUp and returns to the over state.
7. The edit button is included in the over state so it appears again.

Since the edit button wasn’t included in the down state, it never had a chance to react to a click event.  Click events occur when the user presses and releases the mouse button over a component and the edit button was not around for that whole chain of events.

Solution: Add the buttons into the downStates so they exist during the entire click action.  Problem solved.

Adobe has made the announcement that AIR developers will be able to create applications for Android in late 2010!  This is exciting news for AIR developers, since it opens up the mobile devices arena.  AIR 2.0 will have support for multi-touch gestures, GPS, accelerometer and screen layout.

Check out the AIR team blog to see their post on the subject.

Personally, I got the Motorola Droid for Christmas, and have been loving it.  I’m quite excited to have the opportunity to develop applications for my phone using technologies I already love and know so well.

Recently, I was racking my brain trying to solve a problem I had with a DataGrid not refreshing data. It took me a while to find the reason, so to help someone else with the same problem, I decided to write about it.

Background

I had an ArrayCollection of custom classes called Build. Those Build classes each had an ArrayCollection another custom class, Item. Item is simply a class with properties key and value. The collection of Items is called metadata. In the Build, I created a getter to go grab the Item from it’s metadata with the key “STATUS”. This way, I can have the datagrid display the properties of each Build as well as the value associated with the metadata Item that has a key of STATUS. Make sense?

Problem

I’d receive a collection of Build objects back from a web service I was polling routinely. After the first call, I’d compare Build id’s and just update the existing Build with the updated information. The problem was, the DataGrid wasn’t showing the updates to the STATUS even though I could introspect with the debugger and see that it was getting updated.

Solution

I found that when I first created a Build instance, I was creating an ArrayCollection to hold the metadata and assigning listeners to watch for changes. I did that to keep it updated. After assigning the listeners, I would go about creating an ArrayCollection of Items and assigning that ArrayCollection to the metadata property of the Build. Did you catch that? My listeners were now listening to an orphaned ArrayCollection.

Moral

Be careful of when you create your properties and assign your listeners. I hope someone out there will be saved a few hours by this little tidbit.

There’s a couple of projects I’ve been working on lately, one of which is the BugQuash QuashBoard, that require a search input. I decided to quit duplicating some of the work I’m doing and create a SearchInput control that extends the TextInput control and wraps the search logic into a reusable component.

The thought process went like this: I wanted a search field that when I typed, the datagrid (or whatever the data was displaying in) would filter out the rows that didn’t match the search terms. FilterFunctions do just that, but they don’t work on the DataGrid or List directly, they work on the dataProvider. The dataProvider must implement ICollectionView to have a filterFunction applied to it. You can figure this out by searching for filterFunction and finding that it is defined in ListCollectionView. ListCollectionView defines the function because it’s in ICollectionView, which ListCollectionView implements. I programmed to an interface, not an implementation.

Continue reading SearchInput control

The next BugQuash is approaching fast (on May 17th) and we’re busy making sure things run smoother this time around.

Bugs In Progress

There’s a lot we’re trying to improve, but one of them is the process by which developers can find a bug to work on or help with. The Adobe Bug System doesn’t have the hooks in it yet to allow a perfect workflow, but we’re getting there. Currently, choosing a bug to work on means you go into the bug system, find the bug you want to tackle and add a comment to the bug that you’re working on it. It’s ok, but if you want to help someone with a bug or provide input or review a bug that had been patched, it wasn’t easy to connect up with that developer.

To remedy that, we’re developing a connect room pod that will allow users to ender the bug number (i.e., SDK-12345) and it will gather the information from the Adobe Bug System and place it in a dataGrid on the QuashBoard that shows bugs in progress. That way, if you want to review someones patch or collaborate on a particular bug, you can see what’s being worked on, in real time.

Continue reading BugQuash improvements

The first Flex SDK BugQuash is now over and we’re pulling together stats and listing things we learned so that future events will be even better.

Here’s some numbers to show roughly how successful the event was:

Total patches submitted: 57

see what got submitted that day
Previous to the event, there were 111 patches submitted since Flex went open source. That means that in one day, the community submitted half of what had been submitted prior to the event. Phenomonal!

Patches accepted: 19 (at the time of this post)

And growing… Twelve patches were able to be reviewed and accepted by the Flex team that day. This was a Saturday and there wasn’t the entire Flex SDK team available, but that is still amazing. Consider that a patch must be reviewed and considered for it’s impact to the SDK by the team. They were working hard to get through as many as they could.

I’ve subscribed to the forums that show when patches are committed to the trunk. There’s been a number of patches accepted since the BugQuash by members of the SDK team.

The Flex team is under a lot of pressure right now since there is the fx name change they are working on, the additional features for Flex 4 and everything else. The fact that they are still working at getting the submitted patches reviewed shows an incredible dedication to the community. They understand that the community worked hard and they are doing all they can to show that it is appreciated.

Participants in person: 60

This is amazing considering we had around 64 register to be there in person. This kind of turnout is unheard of. There were people attending from Vancouver BC, Utah, Dallas, Atlanta, Portland, Tacoma and Spokane.

Participants online: 122

That’s huge. The connect room had over 50 people in it all day. Many people broke off into ConnectNow rooms to collaborate with other online participants so it’s hard to track exactly how many. The fact that we had 244 registered to participate online means that 50% of those registered actually participated. This number might be a little off since we know that some registered to participate but participated in groups, sharing the connect room so the actual number is probably slightly higher. I am also impressed that even when the event was winding down, the connect session was still going strong.

Here’s a video of Nate and I discussing the event with Ryan Stewart.

Marty and Nate Talk About BugQuash from Ryan Stewart on Vimeo.

I’d like to personally thank my wife and Nate’s wife for supporting us while we were preparing for the event.