Hack to make layout borders visible in Flex

I put together this quick hack to show the borders of all the containers in a flex application – I found myself wishing for something like firebug’s inspector for flex while spending way too much time debugging a pixel precise layout this week This biggest problem for me was figuring out which control or container was contributing padding to the layout in places where the alignment was off, and it appeared that some of my styles in an embedded css file weren’t working.

The code inserts a canvas over the contents of the application, disables its mouse events (making it transparent to the app/user) and then listens for mouse move events on the Application object. Each time the mouse moves, it queries the display list to find out what’s under the mouse, then draws outlines around that control and all of its parents.

There’s obviously a lot more that could be added to this – like shading padded regions, having a tool tip display which control you’re over along with attributes, but as I don’t know when I’ll have the time (and more importantly the inclination) to make those enhancements happen, I’m putting it up now.

You can right click on the example to view the source. If the embed isn’t working, you can go here where all the flash player autoinstall magic will happen.

Note: this will only work in your application if your root application object has absolute layout because of the way flex containers work- i.e. only containers with absolute layout allow overlapping controls. I had some code that attempted to reparent the children of the application if it had vertical or horizontal layout, but the guts of flex were throwing an error so that code is commented out presently.

Loading Flex from a Flash 8 swf; Actionscript-only version checking

Not too long ago, I was poking around the internets trying to figure out how to load an Actionscript 3 (Flex) SWF file from a Flash 8-compatible (AS2) swf after version checking the player to see if it is version 9 or greater. I managed to piece together what I needed and went on my merry way.

Yesterday someone who had seen my queries on the flexcoders mailing list wrote to me to ask if I had found an actionscript-only solution after all, so I will post the solution here for future reference. I certaintly couldn’t have come up with this without tidbits from here and there…

The key to this working is not loading anything onto the stage before running this code. In fact, in my solution, I use a flash project that only does version checking and loads SWFs externally for both cases where flex is supported and where it isn’t. Insert something like the following in the first frame of your timeline and you should be all set.

var FLEX_NOT_SUPPORTED_SWF ="absolute path to a flash 8 or below swf";
var FLEX_SUPPORTED_SWF = "absolute path to a flash 9 swf";
var versionInfo = getVersionInfo(); // use your favorite implementation of this
if (versionInfo.majorVersion >= 9)

Flex and REST don’t get along

I was a bit dismayed on Friday to find that Flex is severely crippled in the way it handles fault responses via the HTTPService component. In short, it doesn’t provide the response body if the HTTP status code indicates an error. It doesn’t even tell you the status code so you can create an intelligent error message. This is easy to do in javascript, so its lame to find that Flex and actionscript are actually less capable in this regard. I found another post describing this issue where blame is placed on the browser implementation.

I had planned to to return HTTP 404 plus an xml fragment containing the error message when a resource wasn’t found via a given id number, but now that’s out the window. Instead I’m always returning OK, and switching based on the body XML content. Oh well.

In order to do so, I needed to determine the root node of the xml – was it “error” or something else? Using e4x, navigating the dom is usually child’s play – just nodename.childname.text() for example. This is where I made a “rookie mistake” in not realizing that the XML object actually represents the root node, not some super-root. So I was testing for the existence of x.error (where x is the XML object, and error would be a first level child) rather than just checking the localname of the xml object, which in fact is the node named “error”. Maybe this will show up in google and help someone experiencing a similar brain-fart one day.