Consider a Flex project with one main application file, a module including a Label with its styleName set to "myLabel", and two CSS files: Main.mxml, MyModule.mxml, main.css and module.css.

The CSS files are included (<mx:Style source=".."/>) in their respective MXML files and look like this:

/* main.css: */
.myLabel {
   color: red;
}

/* module.css: */
.myLabel {
   font-style: italic;
}

When you run this application and load in the module with the Label in it you'll notice that it is colored red, but its text is not italicized.

If you set the -keep-generated-actionscript argument to true in the compiler-settings* you can have a look under the hood of the Flex framework and see what actually happens here. Once the compiler has run you'll have a new folder called 'generated' in the 'src' folder of your project, this is where all the classes go that Flex auto-creates for stuff like data-binding and also embedded styles.

Somewhere in the generated folder there should be a class called MyModule-generated in which there's a method called _MyModule_StylesInit():

In the above code Flex starts by looking for an existing style-declaration for the stylename "myLabel" and if there is none it'll create a new one -- in our case there already is a style-declaration however (as we've made one in main.css).

Next, Flex examines the factory-property of the style-declaration (a CSSStyleDeclaration instance). The factory-property is a function that defines all style-values that were set at compile-time from the class associated with the generated class (in this case MyModule.mxml). The value of CSSStyleDeclaration.factory is usually generated by the compiler (as you can see on line 152-155).

This part of the method is where things go wrong; by only updating the factory if it is null, Flex assumes that a compile-time style-declaration can only be set at one location in your project -- whereas we set it at two (Main.mxml and MyModule.mxml).
Because the factory-property of our style-declaration has already been set when the styles from main.css were initialized (by similar auto-generated code for Main.mxml) the styles from module.css will be disregarded.

I at the very least hope this might save some other developers from hours of searching around their code, let me know. Also, this a good read if you want to familiarize yourself on the topic of modules and CSS in Flex:
viconflex.blogspot.com/2007/04/flex-modules-compile-and-run-time-css.html

* Configure the compiler by setting options in the 'additional compiler arguments' field of the project properties window (right-click your project, go to 'properties' and then 'Flex Compiler').

"Could not resolve <mx:ToolTip> to a component implementation."

So why does Flex (or rather MXMLC, the compiler) let you write <mx:Button> and <mx:Canvas> and all those other Flex components, but not <mx:ToolTip> -- it's a native Flex class and it's in the mx package just like all of the others, right?

Fact is, it's not the mx class-package that defines whether or not you can add a component by saying <mx:...>, but rather the Flex component manifest file -- it describes which of the native Flex classes fall under the mx xml-namespace (or actually any namespace you want to use). I might write a post about manifest-files in Flex somewhere in the near future, but for now you'll have to read up in the docs if you want to know more.

It so happens that the ToolTip class isn't included in the native Flex component manifest, and consequently the compiler won't be able to find it if you just write "<mx:ToolTip />". You can work around this by specifying a seperate xml-namespace for the mx.controls package:

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:controls="mx.controls.*">
    <controls:ToolTip />
</mx:Application>

Note that in the above example we can't change the value of the xmlns:mx attribute so that it would point to the mx.controls class-package, because if we would then the compiler wouldn't recognize the <mx:Application> tag anymore (since the Application class isn't in the mx.controls package).

Also, for the naysayers who completely miss the point and start talking about why on earth you would want to instantiate a ToolTip through mxml: To tell the truth I was wondering about this myself, but if you think about it, tooltips in Flex aren't restricted to just having whatever you put into UIComponent.toolTip automatically pop up when you mouse-over. In fact you may want to create a custom mxml-component subclass of ToolTip and manually add it to your application using the ToolTipManager class during runtime.

That having been said, ToolTip isn't the only Flex-class not included in the Flex component manifest, naturally what I wrote in this post also applies to any other class in the Flex framework that extends UIComponent but isn't included in the manifest.

In short, the bug occurs with Flash content playing H.264 video in Internet Explorer with certain version of the Flash Player older than 10.0.32.18. Under these circumstances, if the video its playhead is set back to the start (seeking) then Flash Player will crash Internet Explorer -- not slowdown-crash, but actually end the process; the browser-window will be closed down (and with that, your Flash application).

We had this bug occur in both Internet Explorer 7 and 8, and upgrading the Flash Player to a newer version (10.0.32.18 or later) made the problem go away. I'm not completely sure whether this problem has been present since HD video functionality was introduced in the Flash Player, or that perhaps it only started later on. The computers we experienced this bug on though, had either Flash Player 10.0.2.54 or 10.0.12.36 installed.

I don't exactly know in which part of the native Actionscript libraries this issue starts, I presume it's in the VideoPlayer class (as I take it that that's where the actual video logic is implemented), but it might as well be in the FLVPlayback component.

Of course any additional information is very welcome, leave it in the comments. Also, there's this one thread in the YouTube Community Help Forums that was somewhat helpful, check it out if you're interested.

(above: Joshua Davis doing the very last session of the conference.)

This post provides some example-code for the concept presented in my previous post, please note that this post serves only to add some concrete material to the abstract idea presented in the previous post and that the focus should be on the latter rather than the former. This post is not at all about best practices or good/bad code-architecture.

I first started thinking about using namespaces for overriding methods when at the end of july I was talking to Tommy about a problem he was having. He had overridden addChild() in some distant DisplayObject subclass but in some situations still needed to use the original implementation of the method. Because for this he used super.addChild() he was forced to put a lot of different logic in that one single subclass.

The implementation of the double-overriding popped up when I suggested to store the original addChild() functionality in a duplicate function defined with a custom namespace and the same name, and then put the rest of the functionality in a subclass of the class that would override addChild():

// DisplayObjectOverridden.as:
package
{
   import flash.display.DisplayObject;
   import flash.display.Sprite;
 
   public class DisplayObjectOverridden extends Sprite
   {
      public function DisplayObjectOverridden ()
      {
         super();
      }
 
      override public function addChild(child:DisplayObject):DisplayObject
      {
         // custom functionality
      }
 
      original function addChild (child:DisplayObject):DisplayObject
      {
         return super.addChild(child);
      }
   }
}

// OtherFunctionality.as:
package
{
   import flash.display.Sprite;
 
   public class OtherFunctionality extends DisplayObjectOverridden
   {
      public function OtherFunctionality ()
      {
         var normalChild:Sprite = new Sprite();
         addChild(normalChild);
 
         var specialChild:Sprite = new Sprite();
         original::addChild(specialChild);
      }
   }
}

// original.as:
package
{
   public namespace original;
}

When namespaces were first introduced in Actionscript 3 I thought it was all pretty cool, but still I sort of had a difficult time thinking of actual use-cases.

What I initially would have liked to use custom namespaces for was to restrict access to certain properties/methods, to only be accessible for certain classes, in the way that private and protected enable you to -- unfortunately there is no simple way of defining who can import your namespace, consequently rendering namespaces somewhat useless for this particular use-case.

Then some time ago it struck me that rather than defining new members with a custom namespace, that you could of course also enhance an existing method instead (I admit this might seem like a no-brainer, but it took me a while to bump into).

Let's say you have a subclass that for regular (outside) usage needs to override a method in the superclass, but itself still needs to use the original (super-) method. You would probably just override the method in the subclass and use super.method() wherever you needed to use the original functionality.
Now let's say that you need to make a subclass of your subclass, which would also require access to the original functionality in said method. All of a sudden super.method() will not work for you anymore.

Here's where namespaces start coming in handy, while still simply overriding the method in the first subclass, you also implement a function with the same name but with your own namespace (for example "original"). Then whenever you need to call the original implementation you can call original::method(), regardless of how deep down in the inheritance-chain you are.

This is only one use-case, you could for instance also use this concept to work around the nasty ambiguous-reference bug you get (or used to get) when declaring a getter and a setter with different (native) namespaces.

To keep the focus on the above described concept I put the example-code in a seperate post, feel free to read on though.

Here's how it works: 'Organisms' (the colored moving squares) are thrown into an infrastructure (a collection of connected points, i.e. the circle/star with connected dots). Each organism is assigned a certain destination-point within the infrastructure and carries with it a pathfinder (a polished version of the algorithm I posted about some time ago).

The pathfinder will figure out which points to travel (trial and error, guessing together a route to the assigned destination, see previous post) in order to reach the destination and will then tell its organism where to go.

When two organisms happen to travel the same connection (line between two points in an infrastructure) they will share and compare their knowledge about several of the paths they have traveled, this is visualised by both organisms becoming semi-transparent.

Here's the rough guide to having spaces in your Flex Builder Actionscript-only project-names:

Kind of leaves me wondering, why all the fuss in the project-wizard if we can rename our projects in the navigator?

A few days later however, I concluded that it was not so much Flex 3 that was causing this issue, but rather Subversion.

Whenever I commited my changes to the Subversion-repository, the latest run-files (Main.swf and Main.html) from the bin-debug-folder on my harddisk would be commited to the html-template-folder in the repository.
As the html-template-folder serves as a template-depot (duh) for your Flex project, any files in it will be copied to the bin-debug-folder after compilation, effectively overwriting your freshly compiled SWF in this scenario.

Initially, this may go by unnoticed, as it will not be untill you update your project (or do a new checkout of the same project), that the run-files will be in the html-template-folder.

I work around this issue by commiting, updating, and removing the run-files from the html-template-folder, but I have yet to come across a proper solution for this problem. So any suggestions are more than welcome. The same goes for any explanation about this strange issue with Subversion..

UPDATE:Through the comments someone exlained where this issue is coming from, here's a quote:

"your bin, bin-debug and html-template directories should *NOT* be committed to svn.

The problem you are having is that it’s copying all of the files in the html-template folder into the bin-debug folder, including the .svn hidden folder. SVN uses the .svn folder to determine where to put the files in the repository, so when you copy that folder, even though it’s in a different folder than when it started, the files will continue to be copied into the original location."

UPDATE: ..also, if you would like to keep these folders in your SVN-repository nevertheless, here's what you'll need to do (credits go to Matthew for this one):

"Goto your project properties and pull up the Flex Compiler tab and the first checkbox you should see says somethign to the effect of “Copy non-embedded files to the output directory”, well uncheck that. This will allow you to keep your bin folders in the repo"

I might've also have called this post "How many more times will I have to re-import my projects into Flex Builder 3!?", this sucks..

Today I decided to work on a project of mine, so I pulled in the latest version from my Subversion-repository and opened up Flex Builder 3.
I started making some additions in classes etc. and eventually I ran the project. To my confusion the SWF I saw didn't reflect any of the changes I'd made, so I made some bigger changes and still nothing changed in the generated SWF.

Long story short, Flex just kept showing me the SWF of an older version of the project. Nothing I did helped; I cleaned the project, refreshed it, renamed it.
Eventually I worked around this issue by deleting the project (not the files) from Flex Builder and creating a new one (same location and same main project-file).

Although I fixed this thing for now, my (fairly big) concern now is mainly about how many more times I will have to re-import my projects into Flex Builder 3..
My guess is that this has something to do with the compiler-cache and incremental compilation, but either way, I'd really appreciate it if the Flex Builder development-team would fix this.

Any suggestions are more than welcome.