The cost of copy/paste in Flex

Sometimes a bug comes around that just sucks out your will to live. It may be incredibly complex, but more often that not it turns out to be something so simple and annoying that you just can't help blogging about it.

We have had a bug in our UI for about a month now that prevents users from being able to copy and paste from *all* popup dialogs in the UI. Now how can that be? Copy and paste just comes along for the ride in every app these days. On top of that, it is probably one of the most used features of any app, globally!

Well it just so happens that today I finally stumbled across the solution. I came across an SDK bug from Adobe (https://bugs.adobe.com/jira/browse/SDK-26182) that discussed how components nested inside of spark panels (speaking Flex 4 here) can't use the context menu items (the right-click menu). As it turns out, this little gem is the exact same bug causing my copy/paste woes. The fix was as easy as setting mouseEnable=true on both my panel subclass and its skin.

How stupid of me you may be thinking. Why didn't I just create a proper skin in the first place, right? Well the thing is, I let Flex Builder create the skin for me...and it set mouseEnable=false in it!

My boss had a great suggestion. He said I should start adding cost info to my blog posts. So here it is...

My team has spent a combined 12 hours debugging how to make copy and paste work in a web-based app. How is that for a waste of time? I'm expecting to be reimbursed by Adobe any day now...

Migrating from Flex 4 Beta 2 to Released Flex 4

After having such an easy time migrating from Flex 3.5 to Flex 4 beta 2, and after having several theme related issues mixing Spark/Halo together in beta 2, I decided to migrate to the released version of Flex 4. Painful!

Here is some of what I have found so far.

1. The mx (halo) namespace switched between the beta and released versions. In Flex 4 beta 2 it is library://ns.adobe.com/flex/halo and in the released version it is library://ns.adobe.com/flex/mx. Still seeing errors? Make sure you have the proper namespaces in your component for fx (Flex), s (Spark), and mx (Halo). See http://www.adobe.com/devnet/flex/articles/flex3and4_differences_03.html for more info.
2. Flex 4 beta 2 was very kind in allowing all mx styling inline. For example, setting the borderSides property on a VBox works fine. The released version no longer allows that. You must either spark-ify them and use a skin or remove the style. It treats these as errors also, so you have to tackle it. FWIW, we removed all borders across our app and no I have to go fix it all!
3. All references to the old StyleManager class must be replaced with FlexGlobals.topLevelApplication.styleManager or a separate styleManager instance. This just shows up as a warning, but several libs we use had it everywhere!
4. This one is the most important because it is hard to debug! If you start seeing errors about not being able to find skins for regular spark classes like Button, Label, Scroller, etc., it is most likely because somewhere in your component hierarchy you have subclasses a spark components and treated the child as a halo component. That does not work. The child of a spark component must also use the fx namespace and the proper mx namespace to run properly. Spent 2 days debugging this problem!

In general I am surprised at how complicated it is to migrate from Flex 4 beta 2 to Flex 4. Why Adobe chose to strip your ability to style old halo components inline makes no sense to me. I know it is now frowned upon, but give me a migration path, not a cliff.

AS3 XMLList and default namespaces

There have been many days where I have relished in how easy Actionscript is to use and how advanced it is as a programming language. Today was not one of those days.

Ever tried to use the XMLList class with XML containing a default namespace? If you have, you already know what I am going to say. If you haven't, you need to know. It doesn't work right!

Nothing happens, literally. The XMLList will just be empty. You have 2 choices at this point. You can set the default namespace using default xml namespace = someNamespace, but that requires setting it back in the same function using default xml namespace = ''. If you don't, be prepared to see errors about accessing invalid registers. Why? Because you are changing the default namespace which has ramifications outside of your little block of code.

The only suitable option is to fully qualify your objects using the namespace. So instead of a accessing an element with myxml..myelement, you must now use myxml..myNamespace::myelement.

I probably could have spent more time on this blog post, but I spent most of my day dealing with the problem being described. Need more info or help? Let me know and I'd be glad to help.

first blog

Finally got a blog up and running! Have a backlog a mile long of things people always said I should blog about...probably won't ever get to them though.

And so for my first blog...

Had a great time last night participating in the Carolina Hurricanes St. Baldrick's event. Organized a team of fellow rPath-ians to get our heads shaved for the cause. We raised over $1,200 dollars along the way!

We got to go on the ice after the game (a 4-3 OT victory for the 'Canes over the Sabres) for a picture of everyone. Was great to be down there! Checked Ben into the boards...it was a clean hit!

Thanks to everyone who participated and/or donated!