My previous trick had a small drawback since selecting a row was also switching a cell to copy mode (read only edit mode).

With this enhanced version, you now have to double click in a cell to switch it to copy mode (using a non editable item editor from which you can copy data). This keeps a standard selection behavior.

Here’s the demo (with source code available):

A few words to highlight how to link the edition to double clicks only.

As you remember, I’m configuring the AdvancedDataGrid as editable and using a read only TextInput as an itemEditor to allow copying data. And now, I’m also allowing double clicks by setting the doubleClickEnabled property of the AdvancedDataGrid.

<mx:Component className="NonEditableTextInput">
    <mx:TextInput editable="false"
        selectionBeginIndex="0" selectionEndIndex="{text.length}"/>
</mx:Component>

<mx:AdvancedDataGridColumn dataField="Field" itemEditor="NonEditableTextInput"
    ...
    editable="true" doubleClickEnabled="true"/>

We still have to avoid the edition to be triggered when single clicking in a cell and my trick to achieve this is to use a third event: itemEditBegin (it is fired just before activating the itemEditor).

<mx:AdvancedDataGridColumn ...
    itemClick="itemClickHandler(event)"
    itemDoubleClick="itemDoubleClickHandler(event)"
    itemBeginEdit="itemBeginEditHandler(event)"
/>

The single and double click handlers just register the latest type of event received and, in the itemEditBeginhandler, we just have to check whether the previous received event was a single or a double click to decide if edition must be allowed or not.

private var doubleClicked:Boolean;

private function itemClickHandler(event:ListEvent):void {
    doubleClicked = false;
}
private function itemDoubleClickHandler(event:ListEvent):void {
    doubleClicked = true;
}
private function itemEditBeginHandler(event:AdvancedDataGridEvent):void {
    // If doubleClicked => allow edit
    // If not => do NOT edit
}

The last trick here is to know how to cancel the itemEditor activation on single click event. Once you know that the itemEditBegin event is a cancelable one, it should become obvious (if it’s not, you may be interested by my article on Advanced Events Management).

private function itemEditBeginHandler(event:AdvancedDataGridEvent):void {
    if (!doubleClicked)
        event.preventDefault();
}

Enjoy!

Enhanced trick to copy data from AdvancedDataGrid from @blogagic on Blogagic.com.

When using a non editable Flex AdvancedDataGrid supporting selection, there’s no default way of just copying the content of a given cell.

The easiest trick I found consists in setting the AdvancedDataGrid as being editable and defining as an itemEditor a simple TextInput configured as not being editable and with its content selected!

In other words:

Ensure your AdvancedDataGrid is defined as editable:

<mx:AdvancedDataGrid editable="true" dataProvider="{gridData}">

Define a non editable TextInput selecting its content:

<mx:Component className="NonEditableTextInput">
    <mx:TextInput editable="false"
        selectionBeginIndex="0" selectionEndIndex="{text.length}"/>
</mx:Component>

And use it as an itemEditor for your AdvancedDataGrid:

<mx:AdvancedDataGridColumn dataField="Field" itemEditor="NonEditableTextInput"/>

Now, when clicking in any cell of the AdvancedDataGrid, the non editable TextInput is displayed with its content selected and ready for copy.

Here’s a working example (with source code available):

In addition, let me take this post as an opportunity to mention a very useful utility site: Mr. Data Converter. Just paste CSV or tab delimited data and it will convert your data into one of several web-friendly formats, including XML, HTML, PHP and.. ActionScript! This is really a good tool when you want to generate some test data for a Flex AdvancedDataGrid in a few seconds

Trick to copy data from a Flex AdvancedDataGrid from @blogagic on Blogagic.com.

• Read the documentation (ASDoc format)
• Read and download source code
• Download the Libagic.swc

for all classes and custom Flex components published on Blogagic.com.

Enjoy!

All Blogagic Flex material is now just one click away from @blogagic on Blogagic.com.

The below explorer application allows playing with almost all configurable properties and styles supported by SparklineLineChart and SparklineLineChart components.

Its usage is supposed to be straightforward, but, in case of any doubt, keep your mouse on the unclear part of the explorer and read the toolTip

Let me know if you found this explorer useful

My Flex SparklineChart custom components now have their own Explorer! from @blogagic on Blogagic.com.

Here are new Flex custom components allowing to easily integrate Sparklines in any Flex application.

If you don’t know yet what are Sparklines, I strongly encourage you to read “Sparklines: theory and practise“, an article written by Edward Tufte, known as the Sparkline inventor.

I thought that it would a good exercise to develop my own Flex custom components for these beautiful Sparklines and I had not been disappointed developing them! Most of the topics that I recently shared with you along my tutorials helped me a lot and were put in practice while developing my two new Flex custom components: SparklineLineChart and SparklineBarChart.

Here is a small demonstration of SparklineLineChart and SparklineBarChart components (right click to view source code):

Click to download source code.
Click to download the BlogagicLibrary.

Here are some key features provided by SparklineChart classes:

• As visible above, SparklineLineChart and SparklineBarChart components can be used as standalone controls or as item renderers in list or data grid.
• They offer different styling options such that you can easily integrate them in accordance with your application’s theme (color, line weight, transparency, …).
• They support a configurable threshold used to determine bar color or to highlight an important area (play with the sliders to see how the threshold value impacts the rendering).
• SparklineChart have a dataProvider property ensuring that the SparklineChart is automatically updated whenever the data changes (use the “Start/Stop timer” check box to see sparklines updated in real time).
• Chart scales can be automatically determined or manually defined.
• Tooltips are optional and can be customized.
• And more! Check the provided documentation for all details.

It was a lot of fun for me developing these components, I hope it will be as fun for you using them!

Sparkline Flex custom components (LineChart and BarChart) from @blogagic on Blogagic.com.

Static vs Dynamic Flex ToolTip

The most common usage of tooltips is to provide hints or simplified help. When hovering on a particular button, for example, the tooltip can provide more details on the consequences of pressing the button. Tooltips are more than welcome, in particular, when buttons are just using icons since it’s not always easy for all of us to guess what the icon means. In such a case, I would call them: Static ToolTips. (By the way, I previously provided some tricks to easily customize your tooltips using HTML tags, take a look if you’re interetsted).

Today, I’d like to focus on Dynamic ToolTips. These are tooltips for which the content (i.e. the tooltip text) must be determined at runtime, just before the tooltip is displayed. You need a Dynamic ToolTip if you want to display in your tooltip any value that changes over time (such as number of downloaded files, number of spam emails, or simply the current time).

The easy way to achieve this would be to listen to an event indicating that the value has changed and, in the corresponding handler, to update the toolTip property of your control. If you would like to display the current time in your ToolTip, you could define a 1mn timer and, each time it would fire, update the toolTip property.

I’m anyway pretty sure that you will all agree that this would NOT be a very good solution since your application would spend CPU cycles to update the toolTip property even if the user would never display the toolTip.

So, a better way to implement this is to rely on tooltip specific events that are generated by the Flex framework for any UIComponent. There are six such events that are fired using the following sequence: toolTipStart, toolTipCreate, toolTipShow, toolTipShown, toolTipHide, and toolTipEnd (for more details, check the event descriptions on Adobe LiveDocs). Let’s see how to use one of them to implement a better Dynamic ToolTip.

Dynamically defining a Flex ToolTip content

The one that is of interest in our case is: mx.events.ToolTipEvent.TOOL_TIP_SHOW.

This event is fired by the UIComponent just before the tooltip be displayed. The generated event (of type mx.events.ToolTipEvent) contains a tooltip property referencing the ToolTip object that will be rendered. On this ToolTip object, there is a text property that contains the text to render in the tooltip (it is filled using the toolTip property of the UIComponent).

So, to update the tooltip content dynamically just before the tooltip be displayed, do something like:

addEventListener(ToolTipEvent.TOOL_TIP_SHOW, toolTipShowHandler);

...

private function toolTipShowHandler(event:ToolTipEvent):void {
	event.toolTip.text = <my dynamic value>;
}

We now have a Dynamic ToolTip showing a dynamic value

But… if the tooltip remains open.. the time doesn’t stop… so your value may keep changing… Wouldn’t you expect the tooltip value to be updated accordingly? If yes, keep reading!

Updating a Flex ToolTip content while it is visible

Here is a pseudo code extract showing how I suggest achieving this:

...
addEventListener(ToolTipEvent.TOOL_TIP_SHOW, toolTipShowHandler);
addEventListener(ToolTipEvent.TOOL_TIP_HIDE, toolTipHideHandler);
<value owner>.addEventListener(<valueChangeEvent>, valueChangeHandler);
...

private var _toolTipVisible:Boolean;
private var _toolTipEvent:ToolTipEvent;

protected function toolTipHideHandler(event:ToolTipEvent):void {
	// ToolTip is not visible anymore
	_toolTipVisible = false;
}

protected function toolTipShowHandler(event:ToolTipEvent):void {
	// ToolTip will soon be visible, we need to ensure its content
	// is up-to-date
	_toolTipVisible = true;
	// Keep the event (trick, see below!)
	_toolTipEvent = event;

	// Do we really need to update the content?
	if (_toolTipDirty) {
		// If yes, update both our toolTip (String) property and
		// the text property of the ToolTip object.
		event.toolTip.text = <my latest dynamic value>;
		toolTip = event.toolTip.text;
	}
	else {
		// The toolTip content will be the value of our toolTip
		// property (this is why we updated it above in addition
		// to event.toolTip.text).
	}
}

protected function valueChangeHandler(value:*):void {
	if (value != _currentValue) {
		// A new value, toolTip content is outdated!
		_currentValue = value;
		_toolTipDirty = true;

		// If the update is received while the toolTip is visible
		if (_toolTipVisible)
			// Update text property of the ToolTip object
			// Trick: manually trigger the tooltipShowHandler with
			// the initial event (containing a reference to the ToolTip
			// object) and you're done!
			toolTipShowHandler(_toolTipEvent);
	}
}

And here we are!

If you found this useful, you would really please me by answering to the following question:

What is the correct way of writing tooltip?
Is it tooltip, tool tip, tool-tip or anything else?

Note: To see a real use case, check my SparklineChart components that are using some Dynamic ToolTips.

Dynamic Flex Tooltips (Updating a Visible Tooltip) from @blogagic on Blogagic.com.

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_COMPLETE: 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)

Flex custom effect EditInPlaceEffect from @blogagic on Blogagic.com.

This is supposed to be transparent for you

If any of you are having issues with viewing my RSS feed, please let me know (simply re-subscribing should help in most cases).

Blogagic now running Google feedburner from @blogagic on Blogagic.com.

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

But, if you want more details and a follow-up of my learning journey, read also the second section!

• FadingInjector Flex custom component
• FadingTextInput or FadingInjector?

FadingInjector Flex custom component

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

Click to download the FadingInjector class.

Use the first ColorPicker to change the controls background color or the second ColorPicker to change the editing color.

Use the “Highlight on Focus” check box to choose between the two available behaviors:

• When checked, the injector changes the control background color into the editing color as soon as the control takes the focus. It then changes it back into the initial control background color on focus out. The change into the initial background color is immediate if the value wasn’t changed; it is done through a fading effect if the value has been changed.
• When unchecked, the control background color is changed into the editing color on focus out, and only if the value has changed.

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

FadingTextInput or FadingInjector?

As I was explaining in my FadingTextInput article, I would have liked my FadingTextInput custom component to support additional features such as a prompt string or a clear button.

I consider that there are already very good implementations of such goodies. Let’s just take two examples:

• The PromptingTextInput component available in flexlib library
• The Clearable TextInput available in Justin W. Opitz’s library

So, instead of extracting these features and incorporating them in my FadingTextInput, I decided to do “the opposite”: extracting my fading behavior and “incorporating” it in these existing components.

Of course, I cannot modify the flexlib or Justin components so why not injecting my behavior in their classes?

The FadingInjector is just an extract from my FadingTextInput component (the part managing and triggering the fading effect) that now applies the fading effect on an external control instead on itself. In other words, you can attach “any” existing control to my FadingInjector and this will add the fading behavior to the control.

I quoted any because my FadingInjector relies on two mandatory elements to be able to monitor a control. The control must support a backgroundColor style and a String property providing its “value” (that can be configured using the valuePropertyName property of FadingInjector). As long as a control has these two elements, the FadingInjector can inject the fading color behavior into the control. As, by default, the value property is defined as “text”, injecting the fading behavior to a TextInput/TextArea (or any subclass of TextInput/TextArea) just requires writing:

<blogagic:FadingInjector id="myInjector" control="{myTextInput}">

So, what’s better compared to my initial FadingTextInput is that I can now easily add my fading logic to any existing customized text input component.

That seems great but… there’s still something bothering me… without really thinking about it, I put my FadingInjector in my com.blogagic.control directory. I don’t think that it’s really a control… so what? You’ll know it by reading my next article!

Note:
Following João’s comment, I added an option to change the background color of the monitored control as soon as it gets the focus.

You should anyway note that this leads to a minor issue when using the ClearableTextInput. Indeed, when tabulating to exit the control, the focus is moved to its internal clear button. So, if you want the fading effect to happen, don’t leave the field using tab, but click on any other control.

By the way, implementing João’s suggestion, I had to modify Darron Schall’s AnimateColor class such that it correctly sets the target values when being interrupted: one less bug, great; thanks again João!

Flex custom component FadingInjector from @blogagic on Blogagic.com.

If you’re just interested by the FadingTextInput component and its source code, check the first section below.

But if you’re curious on why I qualified it as an Edit in Place building block or want a clue concerning the next article, don’t forget to read the second section.

• FadingTextInput Flex custom component
• FadingTextInput: an “Edit in Place” building block

FadingTextInput Flex custom component

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

You can download the FadingTextInput class.

I hope that the source code is commented enough to explain the approach I took when building this Flex custom component. Anyway, if anything remains unclear for you, don’t hesitate to ask for clarifications by leaving a comment.

FadingTextInput: an “Edit in Place” building block

After having read Designing Web Interfaces by Theresa Neil and Bill Scott, I decided it would be fun to work on some Edit in Place components. And, of course, it would also be a good step in my Flex learning journey!

I decided to start by customizing a Flex TextInput such that, at the end of the editing process, its background color fades from the editing color to the regular background color.

My first result is the FadingTextInput custom component (see FadingTextInput in action above).

While developing this FadingTextInput custom component, I was having one new idea every two minutes! So it was quite difficult to remain focused on completing something instead of continuously wanting to change everything

The main aspects I kept in mind were: Invitation & Fading.

For the Invitation part, I added customizable tooltips and decided that the border of the FadingTextInput would be drawn only when hovering over the control.

For the Fading part, I was lucky to discover Darron Schall’s AnimateColor class since I’m not (yet) using Flex 4 (which provides this effect natively).

After having completed these two objectives, I looked at my todo list and found: “manage a prompt string when the field is empty”. Nice! Let’s google it… ouch… so many results! and all of them are, as my FadingTextInput, a customized version of TextInput.

So, now that I have a lot of brilliant TextInput sub classes providing very good implementations of the prompt string requirement, what do I do with my own FadingTextInput? Do I update it to incorporate extracts of the other classes I found? Do I contact the other developers asking them to integrate my own features in their components?

I don’t think so!

This made me realize that my approach could have been better.

But, this will be for the next article!

Flex custom component FadingTextInput (Edit in Place building block) from @blogagic on Blogagic.com.