Fade to Gray Modal Window Flex Effect

I’ve always liked the effect Windows XP gives you when you select Shut Down… and it then gives you the Shut Down, Restart, Log Off etc options in a modal window. If you leave that window in place for a second or so, your desktop slowly fades to gray while your modal window stays full color. I’ve been wondering for a while whether that effect was possible in Flex.

So, the simple answer is yes. Wait for this example to load, hit the Launch Popup button and watch the background image (you’ll need Flash Player 9).

So, how does it work? Flex 2’s PopUpManager class has an undocumented internal property called modalWindowClass. By setting that property to a class definition of your choosing, an instance of your class is created when you create a modal popup window. This instance sits “behind” your modal popup, affecting the appearance of the application. These windows are often called popup blockers.

I’ve created a popup blocker class (SaturationFadePopUpBlocker) that uses a new SaturationFade effect I’ve also written. The SaturationFade effect changes the color saturation level of component that is the target of the effect using an instance of the Flash Player’s ColorMatrixFilter.

To add the popup blocker to a Flex 2 application is very simple. The following is the single line of code that is required add the above popup blocker effect (alongside the need to import the necessary classes).

PopUpManager.mx_internal::modalWindowClass = SaturationFadePopUpBlocker;

The SaturationFadePopUpBlocker and SaturationFade effect classes can be downloaded as a Compiled SWC (inside this zip) or as a Flex Builder Library Project. The Library Project includes the compiled SWC and all the source code.

Although this example fades the background to gray, the SatuationFade effect I have written lets you change the color saturation of a component to any level, including making it brighter. The start and end saturation levels, along with the duration of the saturation fade, are all customisable in the Saturation effect and SaturationFadePopUpBlocker classes.

The SaturationFade effect class can also be used as a standalone effect, in place of any of the existing Flex framework effect classes. In this example, the SaturationFade effect plays when you hold your mouse down over the image, with the color saturation level fading from 1 to 0. The saturation level animates back to 1 when you let the mouse go:

The code for the above example is:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:eff="com.adobe.effects.*" >
import com.adobe.effects.SaturationFade;
<eff:SaturationFade id="fadeToGray" duration="500"
saturationFrom="1" saturationTo="0"  />
<eff:SaturationFade id="fadeBack" duration="500"
saturationFrom="0" saturationTo="1" />
<mx:Image mouseDownEffect="fadeToGray" mouseUpEffect="fadeBack"
source="sunset.jpg"  />

I won’t go into detail about the implementation of the classes for now. The SaturationFadePopUpBlocker class is very small and should be fairly self-explanatory to most people. If there’s a demand, I’ll do a future post about creating effects using the Flex effects framework and, in particular, how the SaturationFade effect works.

Open Source Flex 2 Calendar Component

A regular discussion on Flex forums such as FlexCoders is the availability, or otherwise, of a good Calendar component for Flex 2.

So, it is with great pleasure that I can announce that the Adobe Consulting team in EMEA will be releasing an open source Calendar framework to the community within the coming weeks.

This is a framework the team here have been working on for a while and Alex Uhlmann is putting the finishing touches to.

Below is a screenshot of a simple Calendar built on top of the framework, which uses the default renderers for the calendar entries and timeline.


Don’t be deceived by the basic look of this example calendar and its surrounding controls – the calendar is built on top of an extremely powerful framework which can be used to build very complicated scheduling components and we’ve spending the majority of our time working on that rather than this example. However, we do plan to ship some better examples with the framework.

Some of the features of the Calendar framework are:

  • Display and manipulate 1000s of calendar entries without losing performance.
  • Define how entries are laid out using the predefined layout manager or by providing your own customized layout manager.
  • Assign custom renderers that can dictate the complete look and feel of your calendar entries.
  • Provide renderers in MXML or ActionScript.
  • “Live” zoom support using zoom API.
  • Use framework effects such as Zoom and Move to make best use of the expressiveness of a Flex RIA in order to achieve the best user experience possible while navigating the component.
  • Efficiently add, remove and update entries at runtime.
  • Assign customized background areas to show office hours, lunch time etc
  • Fully stylable
  • Ability to select calendar entries with visual highlighting
  • Consistent in usage with the Flex Framework, eg. dataProvider driven
  • Broadcasts events to help interaction development
  • Can be used in MXML or Actionscript
  • And more…

To give a glimpse of the API of the calendar, here’s the MXML used to create the above example. However, please note that we are still defining the API, so it may change in the final version.

width="600" height="400"
dataProvider="{ appointments }"
startDate="{ new Date() }"
duration="{ DateUtil.DAY_IN_MILLISECONDS }"
zoom="{ zoom }"
itemLayoutManager="com.adobe.calendarClasses.BestFitLayoutManager" />

We’re very excited about this contribution to the Flex community and, in time, look forward to seeing it used within your Flex applications.

Finally, in expectation of the being asked the obvious question, and following in the footsteps of all good delivery teams, the answer is “It’ll be ready when its ready” 😉

Cairngorm 2 – ASDoc Available

You may have seen by now that we have released Cairngorm 2 for Flex 2 over on Adobe Labs.

The Cairngorm 2 release on labs contains the source code only at the moment, but we’re very busy in the background putting together more Cairngorm documentation and samples for the Flex community.

So, with a huge thanks to Brian Deitte of the Flex Team, we’re able to provide you with the API documentation for Cairngorm 2. These docs can be downloaded from here for now, but we’ll get the up on labs over the next few days.

The API docs are in the same ASDoc format as the Flex 2 Documentation, so should be immediately familiar to you.

I’ve already noticed a few formatting errors in the docs, and we will get those fixed for the release we put on labs, but please let us know if you think anything needs changed or updated in the meantime.

You can download the Cairngorm 2 documentation here.

Cairngorm 2 Stateless Commands

You may have seen over on Steven Webster’s blog that Cairngorm 2 for Flex 2 Beta 3 has been released.

The main change in this release, compared with previous releases, is how commands are instantiated and used. I’d like to touch on the motivation behind this change.

In Cairngorm for Flex 1.x, a single instance of each command was instantiated by the controller and that one instance is used for each and every invocation of the command.

There are reasons why the original implementation was done in such a manner, mainly historical due to Cairngorm originally being developed for Flash applications, but since the advent of Flex, we’ve wanted to change it. With the API scrub taking place between Flex 1.5 and Flex 2, we see now is a good time to make this change.

Steven explains on his blog the single change you’ll have to make to your concrete front controller because of this API change.

So now, rather than the single instance of the command being used for each command invocation, the front controller now instantiates a new instance of the command on each invocation. There are a couple of implications here:

1) If, in your existing Cairngorm applications, you rely on the same command being used for each command invocation, (eg, if you store state in the command, and reuse that state on the next invocation), you will have to change your implementation. What we’d recommend here is that you store your state in your model, possibly via the ModelLocator pattern.

2) Because a new instance of the command is instantiated on each command invocation, you can now store local state in that command for the duration of its invocation. This is particularly useful for cases where you make server side calls (eg, via RemoteObject). Previously, you’d have to use a pattern such as the Asynchronous Completion Token, but now, you can store your state in a command’s instance variable in the execute() method (for example, you may store the event object), and then retrieve it again in your result or fault handler. We find this useful for cases where you want to update different parts of the model in the result handler, depending on the context of the initial command execution.

So, go get Cairngorm 2 for Flex 2 Beta 3 and let us know what you think.


After months of activity (and inactivity) over on the old iteration::two blog I have my own blog now here.

Over the weeks and months ahead, I hope to give you an insight into the world of Adobe Consulting, showing you some of the things we’re doing with the Adobe product set, particularly Flex, and also sharing my thoughts on where I see the Rich Internet space heading.

So, keep tuned and come back soon!