I was recently asked to troubleshoot some legacy code where an HTTPService call was (sometimes) failing on the server side due to malformed XML payload in a String parameter.  On the client side, the XML was being created as a String from user input, which opened the door for invalid characters to be injected directly into the markup.

Rather than refactor the process that generates the XML altogether, I set out to see if there was a simple approach to simply escape the special characters and keep the rest of the String intact. I started to explore functions like HTMLEncode, thinking I could find functionality similar to what I needed.

Ultimately, the solution was far simpler.

It turns out that casting an XML-formatted String to an instance of the XML class handles special characters and performs all of the necessary logic to escape any offenders. So by simply constructing an XML object from the source String, then calling toString() on the XML object, we can effectively sanitize the original String into valid markup that can be parsed as expected.

Nifty.

When working in Eclipse/Flash Builder, occasionally something wacky will happen in a project or the workspace itself that causes the following message to appear: "An internal build error has occurred. See the error log for more information." In some cases, a refresh and/or clean of the project in question is enough to straighten things out. But if that were always the case, this would be a very short blog entry, and that's not really my style.

I recently encountered the "internal build error" monster when working with a Flex module I hadn't touched in months. I simply opened it up and tried to build it, and I was instantly on my way to bang-my-head-against-my-desk-in-frustration territory. Nothing about the project had changed, so all signs pointed to something in the development environment. But what?

[More]

This has been a source of frustration for such a long time, I had to share the solution. Credit for this one goes to Martin McBrearty, and there are a few other blogs out there that support this method.

Important Disclaimer: This method does not appear to be officially supported, and is not guaranteed by me or anyone else to work. Use at your own risk!

[More]

Today I spent hours tracking down a bug related to inserting and/or deleting data from a Tree control. In certain circumstances, an update to the underlying dataProvider would cause the following to be reported:

After a bit of Googling, I found that I am not alone. Other folks have the same issue with Tree. Even more common, it looks like people are getting the same error when manipulating data in an AdvancedDataGrid, in which case it is reported as:

After drilling down into the Flex Framework source and exploring the makeRowsAndColumnsWithExtraRows function, I added some watch expressions in the Flash Builder Debug pane. (The debug features are really, really useful for this kind of thing.) The culprit? The value for verticalScrollPosition was being reported as -1, causing a line of code to look for an array element at index -1. This array element was in turn undefined, so the error message suddenly makes perfect sense.

The real puzzler here is that verticalScrollPosition could ever be less than zero. This is the logical equivalent of scrolling to the top of the list, then scrolling up one more spot, which is of course impossible. In any case, I have decided to assume that -1 is invalid at all times, and that -1 really means 0. I hope that is a safe assumption!

So, the solution is simple. In my case I had already subclassed the Tree control. If you're using the stock control from the framework, you'll need to subclass it and simply add the following:

All it does is intercept any request for verticalScrollPosition and guarantee that it is greater than or equal to zero. In brief testing, the error has disappeared and I have seen no side effects.

Like anything else on this blog, use this fix at your own risk, since I can't guarantee it won't have any negative impact.

Happy coding!

I recently took on the task of a major refactor of an AIR project. The application had grown into a monolithic beast with lots of conceptually related but logically disparate functionality. Management of the code was becoming a challenge. Packages were poorly structured. It was a mess.

The real catalyst for change, though, was the compile time. It had gradually crept up from a few seconds to 30+ seconds. In an effort to return to acceptable levels, I broke out chunks of UI into modules within the main project. I pulled graphics and sounds assets into a separate library SWC. But there was no appreciable effect.

The plan of attack was to break out at least two sections of the application, which are essentially mini-applications on their own. They share only a few common aspects of the main application, such as a common model and server connection manager, and are otherwise self-sufficient. Luckily, the project is built on Cairngorm principles, meaning that these items are already more or less detached from the view components.

What follows is a set of principles for successfully breaking down a large Flex application into separate, manageable module-based projects. These techniques seemed to have worked for me, although of course it is still a work in progress and there is much optimizing left to do. Really, this post is probably more for me as a future reference than anything else, but if it can help someone else, that would be terrific. Your mileage may vary, and if it does, leave me a comment to let me know what you've done differently!

[More]