Flex textarea control not updating properly - apache-flex

I am writing a flex application that involves modifying a textarea very frequently. I have encountered issues with the textarea sometimes not displaying my modifications.
The following actionscript code illustrates my problem:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" minWidth="955" minHeight="600">
<mx:TextArea x="82" y="36" width="354" height="291" id="textArea" creationComplete="initApp()"/>
<mx:Script>
<![CDATA[
private var testSentence:String = "The big brown fox jumps over the lazy dog.";
private var testCounter:int = 0;
private function initApp():void {
var timer:Timer = new Timer(10);
timer.addEventListener(TimerEvent.TIMER, playSentence);
timer.start();
}
private function playSentence(event:TimerEvent):void {
textArea.editable = false;
if (testCounter == testSentence.length) {
testCounter = 0;
textArea.text += "\n";
}
else {
textArea.text += testSentence.charAt(testCounter++);
}
textArea.editable = true;
}
]]>
</mx:Script>
</mx:Application>
When you run the above code in a flex project, it should repeatedly print, character by character, the sentence "The big brown fox jumps over the lazy dog.". But, if you are typing into the textarea at the same time, you will notice the text the timer prints is distorted.
I am really curious as to why this happens. The single-threaded nature of flex and disabling user input for the textarea when I make modifications should prevent this from happening, but for some reason this doesn't seem to be working.
I must note too that, when running the timer at larger intervals (around 100ms) it seems to work perfectly, so I am tempted to think it's some kind of synchronization issue in the internals of the flex framework.
Any ideas on what could be causing the problem?

My son is having a rough go at this teething thing, hense my being awake. AND, I'm not really sure how I happened upon this random question/answer since I'm so rarely on stackoverflow.... but...
You SHOULD NOT have to increase your framerate by 4x because of a textArea! We're talking about system resources, not to mention a very elegant flex framework that you could instead leverage:
Here's a very quick, and flex-sdk compliant and happy fix:
create a component that extends TextArea and add the following property and override (if this in fact what you're trying to do):
private var _tackOnText : String = "";
private var _tackOnTextChanged : Boolean = false;
public function set tackOnText(value:String):void
{
_tackOnText = value;
_tackOnTextChanged = true;
invalidateProperties();
}
public function get tackOnText():String
{
return _tackOnText;
}
override protected function commitProperties():void
{
super.commitProperties();
if(_tackOnTextChanged) {
this.textField.text += _tackOnText;
_tackOnText = "";
_tackOnTextChanged = false;
}
}
Then change your playSentence to do this:
if (testCounter == testSentence.length) {
testCounter = 0;
textArea.tackOnText += "\n";
}
else {
textArea.tackOnText += testSentence.charAt(testCounter++);
}
This is one fix to a semi-common problem that should allow you to not increase your frameRate by 4x to get your app to function correctly AND you'll be better working with the flex sdk.
My 2p.
Have a good one,
Jeremy

the problem you are facing seems to be when the addition ticker function is called at the same time that you are entering text, by entering text manually it seems that it is then missing the addition of the text. though im not sure why.
the solution i found seems to be to make sure that the framescript and timer dont meet (for the faster text input, increase the framerate) for 10ms timer 100fps seems to work without any problems (add frameRate="100" to mx:Application line).

Related

Custom Composite Control not rendering correctly for only 0.5-1 sec after being added back into a VGROUP

I am moving away from MXML and have built a custom component control within ActionScript.
I have the control displaying correctly. The problem comes after I remove it from the display list and add it back in again with the .addElement(control) method.
Here is the code that adds it back in again.
private function displayParameters(parameters:ArrayCollection):void{
for(var index:int = 0; index<parameters.length; index++){
if(parameters[index] is ReportControl){
var control:ReportControl = parameters[index] as ReportControl;
control.percentWidth = 100;
vgParameters.addElement(control);
}
}
}
ReportControl is the base class for comboBoxMultiSelect which is shown below. There is nothing graphically special about ReportControl, it only serves as a programmatic interface for its concrete implementations (polymorphic).
public class comboBoxMultiSelect extends ReportControl{
[Embed("../Assets/Icons/plus-16.png")]
private var plusIcon:Class;
[Embed("../Assets/Icons/minus-16.png")]
private var minusIcon:Class;
private var expanded:Boolean = false;
private var buttonIconChanged:Boolean = false;
private var _drp:ComboBox;
private var _btnMultiple:Button;
private var _horizontalGroup:HGroup;
private var _multiSelector:ReportGridSelector;
private var _multiSelection:Boolean = true;
private var bMultiSelectionChanged:Boolean = false;
public function ToggleExpanded():void{
expanded = !_expanded;
buttonIconChanged = true;
invalidateSize();
invalidateProperties();
invalidateDisplayList();
}
public function comboBoxMultiSelect(){
super();
}
override protected function createChildren():void{
super.createChildren();
if(!_horizontalGroup){
_horizontalGroup = new HGroup();
_horizontalGroup.gap = 0;
_horizontalGroup.percentWidth = 100;
_horizontalGroup.height = ReportControl.SIZE_DEFAULT_HEIGHT;
addChild(_horizontalGroup);
}
if(!_drp){
_drp = new ComboBox();
_drp.text = GuiText;
_drp.percentWidth = 100;
_drp.height = ReportControl.SIZE_DEFAULT_HEIGHT;
_horizontalGroup.addElement(_drp);
}
if(!_btnMultiple && _multiSelection){
_btnMultiple = new Button;
_btnMultiple.setStyle("icon", plusIcon);
_btnMultiple.width = 20;
_btnMultiple.height = ReportControl.SIZE_DEFAULT_HEIGHT;
_btnMultiple.visible = true;
_btnMultiple.addEventListener(MouseEvent.CLICK,
function(event:MouseEvent):void{
ToggleExpanded();
});
_horizontalGroup.addElement(_btnMultiple);
}
}
override protected function commitProperties():void{
super.commitProperties();
if(buttonIconChanged){
if(_expanded==true){
_btnMultiple.setStyle("icon", minusIcon);
}
else{
_btnMultiple.setStyle("icon", plusIcon);
}
buttonIconChanged = false;
}
}
override protected function updateDisplayList(unscaledWidth:Number,
unscaledHeight:Number):void{
super.updateDisplayList(unscaledWidth, unscaledHeight);
_horizontalGroup.width = unscaledWidth;
_horizontalGroup.height = unscaledHeight;
}
override protected function measure():void{
super.measure();
measuredMinWidth = measuredWidth = ReportControl.SIZE_DEFAULT_WIDTH;
//minimum size //default size
if(_expanded==true)
measuredMinHeight= measuredHeight = 200;
else
measuredMinHeight= measuredHeight =
ReportControl.SIZE_DEFAULT_HEIGHT;
}
}
When I add the control back in using vgParameters.addElement(control), the comboBoxMultiSelect is not rendering properly. The plusIcon inside the button _btnMultiple is not postioned correctly at first, but then quickly corrects itself about 0.5-1 secs later.
I pretty sure the problem lies within comboBoxMultiSelect, just not sure how to force the icon to stay in the same place.
This is highly annoying after all my hard work, anyone have ideas as to what I am doing wrong?
Thanks :)
UPDATE -----> Here is the ReportControl code
[Event (name= "controlChanged", type="Reporting.ReportControls.ReportControlEvent")]
[Event (name= "controlIsNowValid", type="Reporting.ReportControls.ReportControlEvent")]
public class ReportControl extends UIComponent
{
private var _guiText:String;
private var _amfPHPArgumentName:String;
private var _reportResult:ReportResult;
private var _sequence:int;
private var _reportId:int;
private var _controlConfiguration:ReportParameterVO;
private var _isValid:Boolean = false;
internal var _selection:Object;
/**
* SIZE_DEFAULT_HEIGHT = 22
*/
internal static const SIZE_DEFAULT_HEIGHT:int = 22;
/**
* SIZE_DEFAULT_WIDTH = 150
*/
internal static const SIZE_DEFAULT_WIDTH:int = 150;
public function get ControlConfiguration():ReportParameterVO{
return _controlConfiguration;
}
public function set ControlConfiguration(value:ReportParameterVO):void{
_controlConfiguration = value;
_guiText = (value ? value.GuiText:"");
_amfPHPArgumentName = (value ? value.AMFPHP_ArgumentName: "");
_sequence = (value ? value.Sequence : null);
_reportId = (value ? value.ReportId : null);
}
public function get IsValid():Boolean{
return _isValid;
}
public function get ReportID():int{
return _reportId;
}
public function get Sequence():int{
return _sequence;
}
public function get ControlRepResult():ReportResult{
return _reportResult;
}
public function set ControlRepResult(value:ReportResult):void{
_reportResult = value;
}
internal function set Selection(value:Object):void{
_selection = value;
}
internal function get Selection():Object{
return _selection;
}
public function get ParameterSelection():Object{
return _selection;
}
public function get GuiText():String{
return _guiText;
}
public function get AmfPHPArgumentName():String{
return _amfPHPArgumentName;
}
public function ReportControl(){
//TODO: implement function
super();
}
public function dispatchControlChanged():void{
this.dispatchEvent(new ReportControlEvent(ReportControlEvent.CONTROL_CHANGED, this, true));
}
public function dispatchControlIsNowValid():void{
this.dispatchEvent(new ReportControlEvent(ReportControlEvent.CONTROL_IS_NOW_VALID, this, true));
}
public function addSelfToValueObject(valueObject:Object):Object{
valueObject[AmfPHPArgumentName] = _selection;
return valueObject;
}
}
I'll try to give you an example of what I mean with the Spark skinning architecture we've discussed in the comments above. It's not directly an answer to your question, but I thought you might find it interesting. I will have to make it somewhat simpler than your component for brevity's sake and because you seem to have stripped out some of the code for your question so I can't know exactly what it's supposed to do.
This will be a component that will let you toggle between a normal and an expanded state through the click of a Button. First we'll create the skin class. Normally you'd create the host component first, but it'll be easier to explain this way.
<!-- my.skins.ComboBoxMultiSelectSkin -->
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
height.normal="25" height.expanded="200">
<fx:Metadata>
[HostComponent("my.components.ComboBoxMultiSelect")]
</fx:Metadata>
<s:states>
<s:State name="normal" />
<s:State name="expanded" />
</s:states>
<s:layout>
<s:HorizontalLayout gap="0" />
</s:layout>
<s:ComboBox id="comboBox" width="100%" />
<s:Button id="toggleButton" width="20"
icon.normal="#Embed('../Assets/Icons/plus-16.png')"
icon.expanded="#Embed('../Assets/Icons/minus-16.png')"/>
</s:Skin>
Thus we've set up completely how your component will look and how it will lay out. Do you feel your headaches dissipating? I for one find this quite elegant. We have the two states and the height of the component will adjust to the currently selected state as will the icon of the Button. How and when the state is toggled is component behaviour and will be defined in the host component.
Now let's create that host component in plain ActionScript. For this we'll extend SkinnableComponent (note that it could also extend your ReportControl if that would extend SkinnableComponent instead of UIComponent).
[SkinState("normal")]
[SkinState("expanded")]
public class ComboBoxMultiSelect extends SkinnableComponent {
[SkinPart(required="true")]
public var toggleButton:IEventDispatcher;
[SkinPart(required="true")]
public var comboBox:ComboBox;
private var expanded:Boolean;
override protected function partAdded(partName:String, instance:Object):void {
super.partAdded(partName, instance);
switch (instance) {
case toggleButton:
toggleButton.addEventListener(MouseEvent.CLICK, handleToggleButtonClick);
break;
case comboBox:
comboBox.addEventListener(IndexChangeEvent.CHANGE, handleComboSelection);
break;
}
}
private function handleToggleButtonClick(event:MouseEvent):void {
toggleExpanded();
}
private function handleComboSelection(event:IndexChangeEvent):void {
//handle comboBox selection
}
protected function toggleExpanded():void {
expanded = !expanded;
invalidateSkinState();
}
override protected function getCurrentSkinState():String {
return expanded ? "expanded" : "normal";
}
}
Allright, there's a lot more going on here.
First look at the SkinState metadata declarations: when a skin class is assigned to the component, the compiler will check whether that skin has the required states implemented.
Then the SkinPart declarations: the name of the property on the host component must exactly match the id of the tag in the skin class. As required is set to true the compiler will check whether these components do really exist in the skin. If you want optional skin parts, you set it to false.
Note that the type of toggleButton is IEventDispatcher: from the host component's point of view, all toggleButton has to do, is dispatching CLICK events. This means that we could now create a skin with <s:Image id="toggleButton" source="..." /> and the whole thing would keep working the same way. See how powerful this is?
Because the skinpart properties are not assigned immediately, we override the partAdded() method which will be executed whenever a component becomes available. In most cases this is the place where you hook up your event listeners.
In the toggleExpanded() method, we toggle the boolean just like the component in your question, however we only invalidate the skin state. This will cause the skin to call the getCurrentSkinState() method and update its state to whatever value is returned.
Et voilà! You have a working component with the behaviour nicely separated into an actionscript class and you didn't have to worry about the layout intricacies. And if you ever wish to create a component with the same behaviour, but it should expand horizontally instead of vertically: just create a new skin that adjusts the width instead of the height and assign that to the same host component.
Oh wait! I nearly forgot to tell you how to assign the skin to the components. You can do it either inline:
<c:ComboBoxMultiSelect skinClass="my.skins.ComboBoxMultiSelectSkin" />
or through styling:
#namespace c "my.components.*";
c|ComboBoxMultiSelect {
skinClass: ClassReference("my.skins.ComboBoxMultiSelectSkin")
}
One thing that stands out is in your implementation of updateDisplayList(). As you know, this is where your component should size and position it's child objects (and/or do any programatic drawing).
But rather than set the child object's width/height directly, you should use one of the Flex lifecycle methods: setActualSize() or setLayoutBoundsSize(). Use setLayoutBoundsSize() with spark components.
When you set a Flex component's width/height, the component will invalidate itself so that on the next update cycle it can be re-rendered. But since you are trying to render the component in updateDisplayList() you should be careful to not invalidate your child objects inside this method.
The setActualSize() and setLayoutBoundsSize() methods set the width/height on a Flex component, but do not invalidate the component.
override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
super.updateDisplayList(unscaledWidth, unscaledHeight);
_horizontalGroup.setLayoutBoundsSize(unscaledWidth, unscaledHeight);
// if you wanted to position objects, you would set their x/y coordinates
// here with the move() or setLayoutBoundsPosition() methods
}
Note, it looks like some child objects are being sized in createChildren() as well ... and it's not really clear what the base Flex component is in this case (what class does ReportControl extend?
Doing it this way may get rid of that rendering glitch. It will most certainly execute less code than if you set width/height properties directly.
[Edit]
It may be an interaction with the HGroup which is kind of unnecessary in this component. While I think making components this way is fun, it can be more tedious... which is why #RIAStar is wisely pointing out another approach.
Some further ideas, if you want to continue down this path:
1) Take a look at the sizing you are doing in createChildren() - for example, the HGroup is given a percentWidth, but in updateDisplayList() it is given a fixed width (this may be a red herring, but I would not set the percentWidth).
2) You might be able to trick the component into validating itself after you remove it or before you re-add it. A hacky hunch that may be a waste of time.
3) Remove the 'HGroup' from your component. It's kind of unnecessary: the layout requirements are simple enough to do w/a few lines of Actionscript. Your mileage will vary as the layout requirements get more complex!
In createChildren() add the combo box and button directly to the UIComponent. Then size and position them in updateDisplayList(), something like this:
override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
super.updateDisplayList(unscaledWidth, unscaledHeight);
var padding:Number = 10;
var gap:Number = 0;
// make the ComboBox consume all of the width execpt for 20px and gap + padding
var availableWidth:Number = unscaledWidth - 20 - gap - (2*padding);
_drp.setLayoutBoundsSize(availableWidth, unscaledHeight); // combo box 100% width
_btnMultiple.setLayoutBoundsSize(20, unscaledHeight); // button is 20px wide
// now position them ...
// probably should not use 0, rather calculate a Y coordinate that centers them
// in the unscaledHeight
_drp.setLayoutBoundsPosition(padding, 0);
_btnMultiple.setLayoutBoundsPosition(unscaledWidth - padding - 20, 0);
}
Thank you both so much for your answers! The consideration and attention to detail in explaining the concepts is awesome! Très bien!
#RIAstar However due to the amount of code already in place, changing my architecture (separating visual element from behavioural) would force to large a re-factor of the code and would cost to much for a feature that hasn't been explicitly requested. (visual representation of the control being able to change at runtime) It certainly is interesting and I will be adding that into a future version.
That said, I think I've been able to find a solution to my problem. I decided to build off of #SunilD.'s suggestion of validating the control before it's added back in. A hack I know, but humans aren't perfect and thus the code aint either. ;-)
When looking at the control, I noticed it was only the button that was having issues with rendering its image. So to test, I added and removed JUST a button instance with an icon, and I saw the same behaviour! (regardless of how comboBoxMultiSelect was implemented) I ALSO noticed that I didn't see the button do this when it was first created. So why not just reconstruct the button when it gets removed from the display list?
I ended up wiring comboBoxMultiSelect to the FlexEvent.REMOVE event, destroy the button reference, create a new one, and add it back in with AddChild(). Below is an explanation of the event.
"Dispatched when the component is removed from a container as a content
child by using the removeChild(), removeChildAt(), removeElement(), or
removeElementAt() method. If the component is removed from the
container as a noncontent child by using the rawChildren.removeChild()
or rawChildren.removeChildAt() method, the event is not dispatched.
This event only dispatched when there are one or more relevant
listeners attached to the dispatching object."
Sure enough, this fixed the icon from displaying incorrectly and explains what happening. For some reason the button is taking more than one render event to apply its style when it's added back in. Anyone else able to replicate this behaviour?
I guess the real question now is "what is the best way to remove and add-back-in a button to the display list, so that its embedded icon is unaffected?"

Is it possible to prevent a flex application from being resized at runtime?

From what I can gather, the resize property of a Flex application is set in the XML config file:
<!--Whether the user can resize the window. Optional. Default true.-->
<!--<resizable></resizable>-->
However, if I set this attribute to true, is there a way to turn this off dynamically at runtime? For example, my application has two view modes - mini and maxi. I would like to prevent the end user from being able to resize the application when in mini mode. I tried prevent the resize using the following code but it does not seem to work:
private function creationComplete():void {
this.systemManager.stage.addEventListener(Event.RESIZE, resizeListener);
}
private function resizeListener(evt:Event):void {
evt.preventDefault();
}
Any help would be greatly appreciated.
There is another way to do that without setting the descriptor file property.
Here is the code:
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" showGripper="false"
layout="vertical" showStatusBar="false"
applicationComplete="init()">
<mx:Script>
<![CDATA[
import mx.events.FlexNativeWindowBoundsEvent;
private function init():void
{
this.stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
nativeWindow.addEventListener(NativeWindowBoundsEvent.RESIZING, onAppResize);
}
private function onAppResize(e:NativeWindowBoundsEvent):void
{
e.preventDefault();
}
]]>
</mx:Script>
Hope this helps.
You'd need to create a new NativeWindow instance and reparent your application into that. When you create a new NativeWindow, you've got options you can set at Initialisation time, including resizable.
http://help.adobe.com/en_US/FlashPlatform//reference/actionscript/3/flash/display/NativeWindowInitOptions.html
According to manual, resizable is read-only property.
So it's probably not possible.
As this was already necro'd, and I was curious:
I was able to implement a switch from resizable to not with the following code:
private var maxMode:Boolean = true;
protected function switchMode():void
{
if (maxMode){
//I chose to freeze the app at current size
//You could also set the min/max to hard coded values
this.maxWidth = this.width;
this.minWidth = this.width;
this.maxHeight = this.height;
this.minHeight = this.height;
}
else {
//default values for WindowedApplication
this.maxWidth = 2880;
this.minWidth = 0;
this.maxHeight = 2880;
this.minHeight = 0;
}
maxMode= !maxMode
}
The user is however still shown the resize mouse icons on the edges of the app.
Try to add return:
evt.preventDefault();
return;

Error in using "removechild"

Below is my code, and the question is explained after it.
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:cal="cal.*"
layout="absolute"
applicationComplete="init()"
xmlns:geometry="com.degrafa.geometry.*"
xmlns:degrafa="com.degrafa.*"
xmlns:paint="com.degrafa.paint.*"
xmlns:containers="flexlib.containers.*"
xmlns:flexlib_controls="flexlib.controls.*"
xmlns:mdi_containers="flexlib.mdi.containers.*"
xmlns:auto="com.hillelcoren.components.*"
xmlns:local="*"
xmlns:components="CollapsibleAccordion.*"
modalTransparency="0.8"
modalTransparencyColor="0x000000"
backgroundSize="100%">
<mx:Script>
<![CDATA[
import c7.views.components.PhotoViewer.PhotoViewer;
import c7.config.ServerConfig;
import mx.core.Application;
import mx.containers.*;
import c7.models.GlobalModel;
private var pv_slideshow:PhotoViewer = null;
private function toggleFullScreen():void
{
if(stage.displayState == StageDisplayState.NORMAL)
{
this.pv_slideshow = new PhotoViewer;
Application.application.addChild(this.pv_slideshow); //added as top-most component to application itself
//set new sizes & go full-screen
this.pv_slideshow.x = 0;
this.pv_slideshow.y = 0;
this.pv_slideshow.width = stage.fullScreenWidth;
this.pv_slideshow.height = stage.fullScreenHeight;
try
{
stage.displayState = StageDisplayState.FULL_SCREEN;
}
catch(err:Error)
{
Alert.show(err.toString());
}
stage.addEventListener(FullScreenEvent.FULL_SCREEN, fullScreenEventHandler, false, 0, true); //intentionally weak referenced
//refresh the display sizes & display list
invalidateSize();
invalidateDisplayList();
}
/*else
stage.displayState = StageDisplayState.NORMAL;*/
}
private function fullScreenEventHandler(event:FullScreenEvent):void
{
if (event.fullScreen) //nothing to do in case when switching to full-screen
return;
//Alert.show(pv_slideshow.width.toString());
//application.removeChild(this.pv_slideshow);
Application.application.removeChild(pv_slideshow); //remove the full-screen container
this.pv_slideshow = null; //reset
//refresh the display sizes & display list
invalidateSize();
invalidateDisplayList();
}
The toggleFullScreen is fired on the click of a button... and it working absolutely fine. But the issue is in "exit" . When I click escape key fullScreenEventHandler is fired and it should remove the pv_slideshow.
This is where I get a null object reference error on the line:
Application.application.removeChild(pv_slideshow); //remove the full-screen container
I have tried using this.pv_slideshow and other such things.
Plz help me figure it out. what am i doing wrong and how should I make it work.
This is exact error message I get:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.core::Container/http://www.adobe.com/2006/flex/mx/internal::removingChild()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\core\Container.as:3315]
at mx.core::Container/removeChild()[C:\autobuild\3.2.0\frameworks\projects\framework\src\mx\core\Container.as:2263]
at index_cloud/fullScreenEventHandler()[C:\development\flex_src\index_cloud.mxml:1661]
I wouldn't use Application.application either.
Please check first pv_slideshow really exists, you can get it's parent ( if has one ) and remove it later.
get the parent
pv_slideshow.parent
remove it from the parent_item
parent_item.removeChild( pv_slideshow )
Make sure also the version of Flex you are using, you may need to remove it with removeElement.
The intended architectural use of Application.application is not to use it as a uiComponent or displayObject, or whatever. If you're building a library project that is doing some calculations based on the application properties, or the application's systemManager, or you need access to the outter application from a loaded module, then you have good reason to use App.app.
You example is not one of those cases. Your best bet is to add your component to 'this' (as long as you're not going to use a "view" container), and do a this.removeChild. That should solve a good chunk of your issues.
Best of luck,
Jeremy

Flex: image switching place in tilelist

I'm running into an odd issue with itemRenderers inside a TileList.
Here is a working example without an itemRenderer: 152.org/flex/
Here is the broken version with an itemRenderer: 152.org/brokenExample/
(I don't have the rep to make both of these a link)
Both examples have "View Source" enabled.
To see the problem use the broken example, select an album and scroll down one row. Scroll back up and the images will be switched. If you try this on the working example it's fine.
This seems to be a widely known bug, but I can't find a solution for it.
UPDATE
I started playing with this example again and found out something else. Turns out you don't have to override the data setter. You can create a new method in the itemRenderer that is set whenever the tile wants to refresh. So the trick is to not rely on the initialize or creationComplete methods.
This is what I have for the itemRenderer in the Application.
<itemRenderers:ImageTile img="{data}"/>
This is the code I have in the itemRenderer.
public function set img(value:String) : void {
trace("setting source: " + value);
this.source = value;
this.name = value.toString().split("/").pop().split(".").shift();
}
I updated my example to reflex this change.
I don't have your app handy, so I can't test end-to-end, but I've looked at your source. You probably need to override the data setter in your itemRenderer:
<?xml version="1.0" encoding="utf-8"?>
<mx:Image xmlns:mx="http://www.adobe.com/2006/mxml" initialize="init()">
<mx:Script>
<![CDATA[
override public function set data(value:Object):void
{
super.data = value;
this.source = data;
this.name = data.toString().split("/").pop().split(".").shift();
}
private function init() : void {
// Removed from your source and transplanted above
}
]]>
</mx:Script>
</mx:Image>
Flex will attempt to re-use item renderers in lists (which means the lifecycle events you might be expecting -- initialize, creationComplete, etc. -- won't always fire), so if you want to be sure your renderer gets updated when the data item changes (as it will when scroll events happen), the best practice is to override the renderer's data property. That'll most likely fix the problem.
Maybe try to invalidate on creationComplete?
From what I recall with DataGrids (which work somewhat similarly to a tilelist), when an item comes into focus its recreated.
<mx:itemRenderer>
<mx:Image id="myImage" creationComplete="myImage.invalidate()" />
</mx:itemRenderer>
Haven't tried this code but I think this is where you want to start looking. I took a look at your itemRenderer component. Try creationComplete instead of initialize to call your function

Two KeyboardEvent.KEY_DOWN events fired with wmode="transparent"

When I listen for key up and key down events with wmode="transparent", I receive 2 key down events followed by a single key up event for the following keys: F-keys, arrow keys, ins, del, home, end, page up, page down, pause, print screen, application key, windows key, and the equivalent numeric keypad keys. The other keys work normally. This is occurring with FF 3.5, but not with IE 6.
Below is a simple Flex application that illustrates the problem if you run it with wmode="transparent".
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" applicationComplete="init()">
<mx:Script>
<![CDATA[
import mx.controls.Label;
private function init():void {
stage.addEventListener(KeyboardEvent.KEY_DOWN, onKey);
stage.addEventListener(KeyboardEvent.KEY_UP, onKey);
}
private function onKey(event:KeyboardEvent):void {
var msg:Label = new Label();
msg.text = event.toString();
eventLog.addChildAt(msg, 0);
}
]]>
</mx:Script>
<mx:VBox width="100%" height="100%">
<mx:TextInput width="100%" text="Hello"/>
<mx:VBox id="eventLog" width="100%" height="100%"/>
</mx:VBox>
</mx:Application>
Our application requires wmode="transparent" and needs to handle both key up and key down events for the problematic keys, so I'm looking for the best way to solve this. What would be the best workaround for this problem? Is there some Flash player parameter that I can use to get this working? (FF configuration changes aren't viable for our application, but might be interesting for understanding the cause of this.)
By the way, the workaround I'm currently favoring is to discard additional key down events for a key during a brief dead-band (maybe 50-100 ms) following its initial key down event. This solution has the merits of being relatively simple to implement while still supporting key repeats, though with an additional delay before repeat begins.
Here's basically what I've added to the test code:
private var keyDownTs:Array = new Array();
private function onKey(event:KeyboardEvent):void {
var msg:Label = new Label();
msg.text = getTimer() + "-" + (isDead(event) ? "**DEAD**" : "") + event.toString();
eventLog.addChildAt(msg, 0);
}
private function isDead(event:KeyboardEvent):Boolean {
var dead:Boolean = false;
switch (event.type) {
case KeyboardEvent.KEY_DOWN:
var ts:int = keyDownTs[event.keyCode];
if (ts == 0) {
// save timestamp for the initial key down event
keyDownTs[event.keyCode] = getTimer();
} else if (getTimer() - ts < 50) {
// this key down is within the dead-band of the initial key down
dead = true;
}
break;
case KeyboardEvent.KEY_UP:
// clear previous key down timestamp
keyDownTs[event.keyCode] = 0;
break;
}
return dead;
}
On my system, the spurious key down events are happening within a few ms of the initial key down (2-6 ms), so 50 ms is looking like a pretty good value. For my production implementation, I think I'm going to put this logic into an EventDispatcher that KeyboardEvent listeners will use instead of listening to the stage directly.
I don't have an answer for you, but can confirm that wmode="transparent" has caused this exact same behaviour with an item on our website. Using transparent and opaque wmodes was causing this unidentified (until now) double keypress behaviour. Due to the numerous issues with opaque and transparent modes, we instead worked around all the other issues that surround using standard mode, because it's the only mode in which keyboard IO works correctly.
Other issues include incorrect key mappings, issues with screen-reading/accessibility software, flash movie does not start executing until it is scrolled into the viewport and others.
If there's any way you can survive without wmode transparent, then consider it, because otherwise, as far as I could see, everything is borked.
The reason we initially chose transparent mode was so we could overlay other HTML elements over the Flash movie. Now instead, if we're going to overlay, we "hide" the flash:
Don't use css display:none because this resets the movie (but not using AX version in IE).
The movie can be hidden by either setting its height to 0.001px via css or to visibility:hidden in css, or both.

Resources