Design Mode Problems Flash Builder 4.5.1

If you have tried to switch to Design Mode in Adobe Flash Builder 4.5.1 and see nothing but white, look at your Design Mode Problems tab: Window > Show View > Other > Flash Builder folder > Design Mode Problems.

If you see this message:

SWC file failed to load. Any component dependent on this SWC file will not be displayed in the Design Mode.

The SWC may have failed to load because of:

*  Incompatible definitions caused by usage of a different SDK version

*  Missing referred class definitions

Switching my SDK from 4.5.1 to 4.5 was a suitable workaround. In my case, my custom mobile skins library depends on sdks4.5.0frameworksthemesMobilemobile.swc which didn’t want to play nice with 4.5.1 apparently.

Swiz 1.0 Review

I have listed some of the popular features and basic differences between Swiz 0.6.2 and Swiz 1.0.0 RC1 and supplied some resources below:

Although the swc file size has grown from 28K to 66K, Swiz still provides punch-packing architecture conveniences that border on alchemy.

Swiz Config

The configuration has been simplified and improved:

<swiz:Swiz id="mySwiz">
<swiz:SwizConfig id="mySwizConfig"

You can now declare your eventPackages and viewPackages paths.

eventPackages – If you point eventPackages=’’, then you can simply reference any event in that package with Class.CONSTANT in the Mediate’s “event” attribute. This allows you to set the actual string value in your Event Class to what ever you want.
Mediator looks like this: [Mediate( event=”MyEvent.SUBMIT”)]
Event constant can look like this: public static const MyEvent.SUBMIT:String = ‘whateva’;

viewPackages – This is an option but will speed up the processing of the display classes.

Beans File

The Beans file looks similar but now is wrapped in a BeanProvider tag:

<swiz:BeanProvider xmlns:swiz=""
<controller:MyController id="myController" />
<delegates:MockDelegate id="mockDelegate" />

Swiz Events

public var dispatcher : IEventDispatcher;

  • No longer do you use Swiz.dispatchEvent instead create a [Dispatcher] and call dispatcher.dispatchEvent and dispatch a standard Flex Event (yay!)
  • On Event Classes that are to be dispatched by Swiz, set bubbles=true so that the event will bubble up the display list, allowing Swiz to listen
  • [Dispatch] allows you to “technically” dispatch events from non-visual components ( somehow it’s always worked with 0.6.4 although it was not supposed to ).

Dependency Injection

  • [Autowire] metadata is no longer used to inject dependencies – instead use [Inject]
  • Inject any individual property of a Bean by specifying the source. ( Injecting an entire bean (or Injection by Name) using the “source” attribute has been available for some time however, I believe Injection of bean properties is new ).

Injection by Type

public var userService : UserService;    // Injection by Type

– or –

Injection by Name

[Inject( source="userController" )]    // Injection by Name

– or –

Injection by property

[Inject( source="userController.currentUser" )]    // Injection by property

Two way Binding

Very cool. Two way binding is supported via the Inject’s twoWay attribute.

[Inject( source="userModel.currentUser", twoWay="true" )]
public var currentUser:User;

Mediate Multiple Events from a Single Method


[Mediate( event="UserEvent.ADD_USER", properties="user" )]
[Mediate( event="UserEvent.EDIT_USER", properties="user" )]
[Mediate( event="UserEvent.DELETE_USER", properties="user" )]
public function mediateUserEvents( user:User ):void
// do stuff

– or –

[Mediate( event="UserEvent.*", properties="user" )]
public function mediateUserEvents( user:User ):void
  // do stuff

Service Helper

Service Helper is similar to AbstractController, however there is a really cool feature where you can pass an array of parameters that are then passed to your result handler eliminating the need to create an extra private var to hold the value from the service caller method over to the result handler.

public function fetchUserRoles( user:User ):void
sh.executeServiceCall( ro.getUserRoles( ), getUserRoles_result, getUserRoles_fault, [ user ] );
protected function fetchUserRoles_result( data:Object, user:User ):void
user.roles = data.result;

Post Construct

[PostConstruct] methods are invoked after all dependencies are injected – for example – setting up a default user after the bean is created.

public function createDefaultUser() : void
currentUser = new User();


New Swiz Website:

The Swiz wiki is very well done. I suggest reading the entire user guide on the wiki:

Brian Kotek has put together a nice demo to explore the new features of Swiz here:

Michael Schmalle has gone a little deeper here:

Flex CSS LinkBar ToggleButtonBar Selected Text Color

Wouldn’t any reasonable coding human assume textSelectedColor to be the color of the text of the selected button in a Flex LinkBar or ToggleButtonBar?

After trying every possible ‘selected’ or ‘active’ CSS tag know to man (actually to Flex), and tracking down every possible path of  inheritance, I embraced one of my coding standards: counter-intuitive measures often prevail over reasonable assumptions.

To my dismay, disabledColor was the ticket. It has nothing to do with the selected state and unlike textRolloverColor and textSelectedColor, it has no mention of ‘text’!

So if I had been smart enough to assume that a selected button is actually disabled, I would have been fine. So when you want to dress up your selected button in your LinkBar/ToggleButtonBar with all kinds of nice-nices, just remember that LinkBar and ToggleButtonBar buttons operate like politicians – just because you’ve been selected does not imply that you’re enabled.

textRollOverColor: #006699;
textSelectedColor: #003366;
/* Yes, this one controls the selected button's text color */
disabledColor: #0099cc;

/*Use DownSkin for Disabled to simulate Active/Selected Button */
disabledSkin: Embed(source="theme1.swf", symbol="LinkButton_downSkin");
downSkin: Embed(source="theme1.swf", symbol="LinkButton_downSkin");
overSkin: Embed(source="theme1.swf", symbol="LinkButton_overSkin");
upSkin: Embed(source="theme1.swf", symbol="LinkButton_upSkin");
font-size: 14;
font-weight: bold;

Slow Compiles in Flex Builder with Multiple Library Projects

At See4th, we are developing an Enterprise AIR application that has a growing number of Library Projects. We hit 10 rather large Library Projects a few days ago and could no longer deal with the pain associated with 2 minute compiles. So the solution took our compile times from over 2 minutes down to 5 seconds! The solution works for both Flex Builder standalone and Eclipse Plugin.

We have created two Eclipse/Flex Builder workspaces. Workspace “A” contains our Library Projects that are tested one at time with a “test harness” or “thin-client”. Since only a few Library Projects are open at any given time, builds are peppy.

Workspace “B” is where our main application lives. Instead of pointing the main application to all 10 Library Projects via App Properties > Flex Build Path > Library Path > Project, we point to src directory of each Library Project via  App Properties > Flex Build Path > Library Path > Source Path.

This has improved compile times significantly: from over 2 minutes down to about 5 seconds. Very nice. And if you use the “Linked Resources” feature of eclipse (ours is ‘FLEX_SERVER_ROOT’), there are no path conflict issues in a collaborative environment.

For those of you who haven’t migrated to the tiny six leg creature to do your compiles and prefer using Flex Builder or Eclipse Flex Builder plugin for the job, this a great way to get huge compile-time performance improvements with very little effort. Additionally, the two workspaces gives you the ability to build modular application components as a swc and improved compile times by accessing the swc’s source path.