I stumbled upon this gem in the Flex API
about the intensity of the setStyle() method on processing. I only
recently had the need to use it and was quite shocked at how slow this
actually was. Granted I used it on a Datagrid which is probably not the
best idea but I'm a bit of a if-it's there-then-use-it-kinda-guy.
Joan Lafferty blogged about the upcoming changes in Moxie for setting component and
sub-component styles. Very insightful article. It immediately made me
ask the question. How does this impact the setStyle() method.
Presumably the "StyleProxy" should alleviate this problem as you have
more control over what style is set to what component, regardless of
the hieracrhy.
See the warning in the Flex api here »
Recently I came across a Flex bug when working on canvas. If you have a canvas with an object centered inside ( horizontal or vertical, it's the same ) and scale this object the result is that the canvas will clip left and top its contents!
To understand what I mean see this example and try to scale the image:
And this is the code used:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" backgroundAlpha="0">
<mx:Number id="scale">1</mx:Number>
<mx:VBox horizontalCenter="0" verticalCenter="0">
<mx:HBox width="100%" horizontalCenter="0">
<mx:Label text="Zoom" /><mx:HSlider value="{scale}" change="{scale = HSlider(event.target).value}" width="100%" />
</mx:HBox>
<mx:Canvas width="200" height="200"
backgroundColor="#EEEEEE" borderColor="#666666"
borderStyle="solid" verticalCenter="0" horizontalCenter="0" >
<mx:Image id="image" source="@Embed('../assets/test.png')" scaleX="{scale}" scaleY="{scale}"
verticalCenter="0" horizontalCenter="0" />
</mx:Canvas>
</mx:VBox>
</mx:Application>
As you can see once the image is scaled and it's bigger that its parent, you wont be able to see it top left corner anymore. This is an annoying bug for me!
Later I found that someone opened a ticket in the Flex bug management system here: http://bugs.adobe.com/jira/browse/SDK-13009
A couple of days ago I received a notification that the bug has been closed... and incredible they closed it as NOT A BUG!
I can understand that finding the bug in a file with 5000 and more lines of code it's not easy and can cause horrible headache, but the reason they gave it's nosense! It's completely a different thing that the reason of this bug.
Moreover what's the connection between flash and html?
Flex have been designed since the 1.0 version as a framework for building RIA (Rich Internet Applications).
A RIA have to behave as a desktop application that runs using the web browser. One of the advantages of Flex agains Ajax is that the first technology provide to the user a behaviour which is much more similar to desktop applications that the one provided using HTML+Javascript. And so my questions is: why should Flex behave like HTML when one of its most important features is to be different from HTML ?
Flex behaves like other SDKs used to develop desktop apps in many situations which are much less important than the one hilighted above. So why close this bug (yes. it is a bug) providing as explanation that it is correct because it behaves like HTML ?
<head> 3d 3d Flash Actionscript actionscript 3 ActionScript 3.0 Adobe Adobe Air Adobe AIR (Apollo) Adobe Flash Adobe Flex AdobeMAX08 AIR AIR Adobe Integrated Runtime Announcements apollo Art AS2 as3 Asides awards Babble BEA Beautiful Web Books Business Cairngorm ColdFusion Community Components Conference Conferences degrafa design dev Development Events Examples Featured Flash Flash CS3 Flash experiments flash player Flex Flex 3 Flex Builder Flex Builder Development Flex Example FMS Fun Gallery General GeoWeb Google Industry Inspiration iphone Jobs Links linux Marketing MAX MAX 2007 Misc News news & events Off topic Open Source Other Papervision3D Parallax Denigrate Personal photos Photoshop Process Processing Resources RIA Singularity Site News Stuff techmology Technology Tennis Thinking Loud Tips Uncategorized Video Whatever