Flex custom effect EditInPlaceEffect

After my custom components FadingTextInput and FadingInjector, here is now a Flex custom effect offering similar possibilities. I called it EditInPlaceEffect.

Check the first section below for a demonstration of the EditInPlaceEffect and access to its source code.

Read the second section if you’re interested by what’s behind

• Flex custom effect: EditInPlaceEffect
• EditInPlaceEffect details

Flex custom effect: EditInPlaceEffect

Here is an application demonstrating the EditInPlaceEffect behavior (right click to view source code):

You can download EditInPlaceEffect.as and EditInPlaceEffectInstance.as classes.

Hover your mouse over the different controls to see the highlight effect or change the controls content to see the background fading effect.

Use the color picker to change the TextInput background color and look at the results (hover or edit the TextInput).

As usual, if you have any question on this component, please leave a comment.

EditInPlaceEffect details

Introduction

If you read my previous article on my FadingInjector custom component, you remember that I concluded by a question: was it really correctly placed in my com.blogagic.control directory? As my FadingInjector isn’t based on UIComponent, the answer is, for me, clearly: No!

So where should I keep it? What is it ?

I would have liked to answer: this is an effect, put it in your effect directory. But… it wasn’t really an effect

So, I decided to turn it into a Flex custom effect and here we are.

Flex custom effect principles (Disclaimer)

I wrote a couple of tutorials on this blog, but nothing (yet) on Flex custom effects. This is because I never really had the opportunity of working on Flex custom effects until now. In other words, I still have a lot to learn about Flex custom effects so don’t hesitate to correct me if you notice any mistake in this article

To be honest, you’ll see very quickly that my first Flex custom effect is not really a classical effect!!!

But, before looking at my very special way of relying on the Flex effect framework, let’s see a couple of reminders on the standard way of defining and using them:

Developing a Flex custom effect requires working with two basic types of classes: factory and instance.

When we create an effect object from MXML or ActionScript, we’re using the factory class.

When the effect is associated to a control for a given trigger (i.e. event), the factory creates an instance of the effect and links it to the target control.

The instance class must provide a play() method that will be called when the effect is triggered (i.e. when the event is triggered) and that implements the effect.

A quite special effect

I said above that my EditInPlaceEffect wasn’t really an effect. What I mean is that I relied on the Flex effect framework to hook my code to a control. Instead of injecting it “from the outside” as with my FadingInjector, this time it’s injected by the effect.

Usually, an effect is associated to a particular event, called its trigger. When the event is dispatched, the effect is played.

In my case, I want to rely on multiple events (ROLL_IN, ROLL_OUT, FOCUS_IN and FOCUS_OUT). I could have defined multiple effects but I would have also needed some needs to share a context between them. And, at the end, using my effects would have required a lot of work to put everything in place.

So, I decided that my Flex custom effect would just be a way to embed my processing in a well known and easily hookable container.

More specifically, the play() method of my EditInPlaceEffect doesn’t animate any property or change any style but, instead, registers the effect instance as a listener for the control. The corresponding event handlers will then do their work “as usual”.

The EditInPlaceEffect effect should not be associated to FOCUS_IN or ROLL_OUT events but, instead, to CREATION_COMPLETE event such that it can define its listeners when the control is created.

I told you it was a quite special effect, hope you’re not disappointed

I still have to check whether effect instances are sometimes recycled as are itemRenderer instances. Of course, if it would be the case, my EditInPlaceEffect would not really remain a valid option! If you know if effect instances are sometimes recycled, let me know.

Comparison with FadingInjector

Compared to my FadingInjector, a few things have changed:

• In a positive way:
  • Injection is easier by using an effect (the control is not required in the effect declaration, it was for the FadingInjector). If a control is renamed, there’s nothing else to change. With FadingInjector, the renaming must be also applied to the control property.
  • Relying on alpha property instead of backgroundColor allows to apply the effect to more controls (there are caveats. With the NumericStepper for example, the fading effect isn’t triggered if you click only once on the arrows. This is because the FOCUS_IN event is received after the value has changed!).
• In a negative way:
  • Not all may like to “alpha = 0.0” look of their controls!
  • When a control is empty, it can be unnoticed by users; it would be better to either always provide a default value or to use controls offering a Prompt facility when they’re empty.

EditInPlaceEffect behavior

To conclude, let me summarize what exactly does EditInPlaceEffect:

• When assigned to a control: sets control’s alpha to alphaRead¹
• On control’s CREATION_COMPLETE2: listens to Focus and Roll events
• On ROLL_OVER, sets control’s alpha to alphaFocus³
• On ROLL_OUT, restores control’s alpha to alphaRead
• On FOCUS_IN, sets control’s alpha to alphaEdit⁴
• On FOCUS_OUT, fades alpha to alphaRead if the value has changed (no fading if unchanged)