March 2011 – Riality Blog

I had an issue recently where there was a standard form item, with a textInput as the entry component. The problem was that a single line was not large enough for the client to enter in the details that they required. Using a text area would be my next logical choice however because of certain real estate restrictions I wanted to keep as many form elements visible on the screen at the one time.

Hence the Expandable Text area, a hybrid of the single lined TextInput and the TextArea. Where typing and removing text would re-size the input component accordingly, and setting a text value would expand the component to cater to the text size.

It’s a fairly simple component with the overridden measure method doing most of the work.

measure

Below in the measure command we utilize both the viewMetrics to determine the number or lines and then the measuredHeight of the TextArea

override protected function measure():void {

super.measure();

// Calculate the default size of the control based on the
// contents of the TextArea.text property.
var lineMetrics:TextLineMetrics = measureText(text);

// get the edge metrics of the textArea
var vm:EdgeMetrics = viewMetrics;
var w:Number = (explicitWidth - vm.left - vm.right);

// calc the line count. If the textFields width has been
// updated to the TextAreas explicit
// height then we can use it's line count otherwise we use
// the lineMetrics width divided
// by the explicit width minus the edges
var lineCount:int = Math.ceil(lineMetrics.width / w);

// use the textFields linecount if it's the layout has been initialized
if(useLineCount){
lineCount = textField.numLines;
}

// include the total for the line height and the
// padding for top bottom and leading values
measuredHeight = measuredMinHeight = (lineMetrics.height * lineCount) + vm.top + vm.bottom + lineMetrics.leading;

}

override protected function measure():void {

super.measure();

// Calculate the default size of the control based on the

// contents of the TextArea.text property.

var lineMetrics:TextLineMetrics = measureText(text);

// get the edge metrics of the textArea

var vm:EdgeMetrics = viewMetrics;

var w:Number = (explicitWidth - vm.left - vm.right);

// calc the line count. If the textFields width has been

// updated to the TextAreas explicit

// height then we can use it's line count otherwise we use

// the lineMetrics width divided

// by the explicit width minus the edges

var lineCount:int = Math.ceil(lineMetrics.width / w);

// use the textFields linecount if it's the layout has been initialized

if(useLineCount){

lineCount = textField.numLines;

}

// include the total for the line height and the

// padding for top bottom and leading values

measuredHeight = measuredMinHeight = (lineMetrics.height * lineCount) + vm.top + vm.bottom + lineMetrics.leading;

}

onTextChange

There is also a listener and handler for the “textChanged” event that is dispatched from the extended TextArea. This handler invalidates the size of the component if the number of lines in the textField has been modified. I also had to sets the variable called useLineCount to determine whether the textFields.numLines attribute should be used. As when the component is first initialized with text, the textFields layout is not yet completely set thus returning an incorrect numLines value.

private function onTextChange(e:Event):void{
if(_prevLineCount != textField.numLines){

// because the lineCount of the textField is not
// set as per the actual size during
// the first phase of instantiation we know that
// it's correct now so we can set a boolean to
// indicate that.
useLineCount = true;

// invalidate the size
this.invalidateSize();

_prevLineCount = textField.numLines;

}

private function onTextChange(e:Event):void{

if(_prevLineCount != textField.numLines){

// because the lineCount of the textField is not

// set as per the actual size during

// the first phase of instantiation we know that

// it's correct now so we can set a boolean to

// indicate that.

useLineCount = true;

// invalidate the size

this.invalidateSize();

_prevLineCount = textField.numLines;

}

updateDisplayList

And the last piece is the updateDisplayList which sets the actual size of the textField based on the number of lines and the components unscaledWidth. It also sets the explicitWidth of the component if it results in a NaN. This occurs if the component’s width is determined by a percentage or layout constraints.

override protected function updateDisplayList(unscaledWidth:Number
, unscaledHeight:Number):void{
// we just need to layout the chrome no need for scrollbars
super.layoutChrome(unscaledWidth,unscaledHeight);

// if the explicitWidth isn't set then set it.
// This will force the invalidateSize() to be called.
if(isNaN(explicitWidth)){

explicitWidth = unscaledWidth;

}

var vm:EdgeMetrics = viewMetrics;

textField.move(vm.left, vm.top);

var w:Number = unscaledWidth - vm.left - vm.right;
var h:Number = unscaledHeight - vm.top - vm.bottom;

// set the actual size of the textField based on the
// number of lines and the default measured minimum
// height of the component
textField.setActualSize(w
,(textField.numLines) * (DEFAULT_MEASURED_MIN_HEIGHT));

}

override protected function updateDisplayList(unscaledWidth:Number

, unscaledHeight:Number):void{

// we just need to layout the chrome no need for scrollbars

super.layoutChrome(unscaledWidth,unscaledHeight);

// if the explicitWidth isn't set then set it.

// This will force the invalidateSize() to be called.

if(isNaN(explicitWidth)){

explicitWidth = unscaledWidth;

}

var vm:EdgeMetrics = viewMetrics;

textField.move(vm.left, vm.top);

var w:Number = unscaledWidth - vm.left - vm.right;

var h:Number = unscaledHeight - vm.top - vm.bottom;

// set the actual size of the textField based on the

// number of lines and the default measured minimum

// height of the component

textField.setActualSize(w

,(textField.numLines) * (DEFAULT_MEASURED_MIN_HEIGHT));

}

There it is, unfortunately it’s written with the Flex 3 SDK although I’ll eventually port it to 4. It’s a hybrid between the two text inputs which will enable the user to concentrate on data entry without having to worry about scroll bars and what they’d typed 50 characters ago.

Previously in Flex 3 List Components came with a style property called the itemsChangeEffect. This allowed you to specify a sequence of effects to apply to the item renderers when a change to the dataProvider occurred.

eg.

 <mx:Sequence id="dataChangeEffect1">
		<mx:Blur 
			blurYTo="12" blurXTo="12" 
			duration="300" 
			perElementOffset="150"
			filter="removeItem"/> 
		<mx:SetPropertyAction 
			name="visible" value="false" 
			filter="removeItem"/>    
		<mx:UnconstrainItemAction/>
		<mx:Parallel>
			<mx:Move 
				duration="750" 
				easingFunction="{Elastic.easeOut}" 
				perElementOffset="20"/>
			<mx:RemoveItemAction 
				startDelay="400" 
				filter="removeItem"/>
			<mx:AddItemAction  
				startDelay="400" 
				filter="addItem"/>
			<mx:Blur 
				startDelay="410" 
				blurXFrom="18" blurYFrom="18" blurXTo="0" blurYTo="0" 
				duration="300" 
				filter="addItem"/>
		</mx:Parallel>
	</mx:Sequence>        

	<!-- This TileList uses a custom data change effect. -->
	<mx:TileList id="tlist0" 
		height="400" width="400" 
		fontSize="30" fontStyle="bold"
		columnCount="4" rowCount="4" 
		direction="horizontal" 
		dataProvider="{myDP}" 
		allowMultipleSelection="true" 
		offscreenExtraRowsOrColumns="4" 
		itemsChangeEffect="{dataChangeEffect1}"/>

<mx:Sequence id="dataChangeEffect1">

<mx:Blur

blurYTo="12" blurXTo="12"

duration="300"

perElementOffset="150"

filter="removeItem"/>

<mx:SetPropertyAction

name="visible" value="false"

filter="removeItem"/>

<mx:UnconstrainItemAction/>

<mx:Parallel>

<mx:Move

duration="750"

easingFunction="{Elastic.easeOut}"

perElementOffset="20"/>

<mx:RemoveItemAction

startDelay="400"

filter="removeItem"/>

<mx:AddItemAction

startDelay="400"

filter="addItem"/>

<mx:Blur

startDelay="410"

blurXFrom="18" blurYFrom="18" blurXTo="0" blurYTo="0"

duration="300"

filter="addItem"/>

</mx:Parallel>

</mx:Sequence>

<mx:TileList id="tlist0"

height="400" width="400"

fontSize="30" fontStyle="bold"

columnCount="4" rowCount="4"

direction="horizontal"

dataProvider="{myDP}"

allowMultipleSelection="true"

offscreenExtraRowsOrColumns="4"

itemsChangeEffect="{dataChangeEffect1}"/>

Because I was writing a Flex 4 Application I couldn’t find anything similar to this property in the Spark List components, so I decided to roll my own utilising a Custom layout for the List Component.

With the Flex 3 itemsChangeEffect you had to wait for your data to change before the effect would take place. With my effect I wanted the user to be able to drag an item around the list with the other elements moving away to allow for placement of the dragged item. Kind of like moses parting the waves with a draggable item.

Writing the custom layout:

Positioning the Elements.

Inside the custom layout it’s the override of the updateDisplayList that does the hard yakka positioning and sizing the List items. It makes sure that the items x and y positions do not overlap or exceed the width of the component. In this instance the first item is in the first row and any subsequent elements are beneath this in pairs.

Drag and Drop

For this layout I still needed the the drag and drop functionality so I extended the TileLayout.
If you still need the drag and drop functionality you may need to override a handful of the methods needed to calculate the dropLocations,indices and the location of the dropIndicator.

calculateDropLocation
calculateDropIndex
calculateDropCellIndex
calculateDropIndicatorBounds

Animating the elements – things to remember

With animating a Flex container you need to set the autoLayout flag to false before the animation to prevent flex from updating the containers layout after a child element is resized or repositioned. Once the animation has finished the autoLayout flag can be set back to it’s default value of true.

override public function updateDisplayList(width:Number, height:Number):void{
	
	...
		
	if(animate){
		
		target.autoLayout = false;
		target.validateNow();
		
		var  trans:Parallel = new Parallel(target);	

		trans.addEventListener(EffectEvent.EFFECT_END,onTransitionEnd);			     
		trans.play();
		
	}
	
}

private function onTransitionEnd(e:EffectEvent):void{		
	
	e.target.removeEventListener(EffectEvent.EFFECT_END,onTransitionEnd);
	target.autoLayout = true;
	
}

override public function updateDisplayList(width:Number, height:Number):void{

...

if(animate){

target.autoLayout = false;

target.validateNow();

var trans:Parallel = new Parallel(target);

trans.addEventListener(EffectEvent.EFFECT_END,onTransitionEnd);

trans.play();

}

private function onTransitionEnd(e:EffectEvent):void{

e.target.removeEventListener(EffectEvent.EFFECT_END,onTransitionEnd);

target.autoLayout = true;

}

Only animate the elements that need animating. This is fairly obvious but can become a real bottleneck especially when dealing with large datasets. Test an elements previous position to determine whether it needs to be included in the sequence.

Depending on your interactivity you may need to set useVirtualLayout to false. Because virtualisation uses an estimate of elements displayed on screen for positioning and sizing, I found that with scrolling and dragging elements beyond the containers current scroll index, these elements were not being resolved. By setting it to false all elements are created and positioned allowing any calculations needed by those not currently displayed on the UI to still be allowed.

You can view and example of the layout here.

You can read more about the Spark SkinnableDataContainers here

Here is a nice article on creating custom layouts with Spark here

Month: March 2011

Expandable Text Area

measure

onTextChange

updateDisplayList

Animating Spark List Items.

Writing the custom layout: