Joeflash’s Enigmacopaedia

Simple Monkeypatch to fix ToolTipManager.destroyToolTip RTE

Posted in Flex, Flex 3 by Joeflash on the March 13th, 2010

So I’m coding a custom tooltip which stays visible when you click on the target (more on that in a future post), so I need to manage the tooltip behaviour with ToolTipManager.createToolTip rather than the UIComponent’s tooltip property, or tooltip events. Ben Clinkinbeard’s monkey patch for ToolTipManagerImpl came in real handy for this.

From this “always on” tooltip, I have a button which asks the user for confirmation before performing the action, after which I dismiss the tooltip. Problem is, an RTE “The supplied DisplayObject must be a child of the caller” always ensues.

Until I realized that calling when a tooltip is showing always dismisses the currentToolTip. So calling ToolTipManager.destroyToolTip on a ToolTip which had already been “dismissed” would of course generate an RTE.

Shouldn’t the ToolTipManagerImpl class be smart enough to figure this out without bugging me with an RTE? Shouldn’t it check first to see if there are children present to remove before attempting to remove them? There may be other situations in my app where I may not always be aware of whether my tooltip is located in the toolTipChildren list.

So, taking a cue from Ben’s monkeypatch, I scrolled down to the next function, and monkeypatched mx.managers.ToolTipManagerImpl.destroyToolTip():

Original code:

  1. public function destroyToolTip(toolTip:IToolTip):void
  2. {
  3.     var sm:ISystemManager = toolTip.systemManager as ISystemManager;
  4.     sm.topLevelSystemManager.removeChildFromSandboxRoot("toolTipChildren", DisplayObject(toolTip));
  5.     // hide effect?
  6. }

Monkeypatched code:

  1. public function destroyToolTip(toolTip:IToolTip):void
  2. {
  3.     var sm:ISystemManager = toolTip.systemManager as ISystemManager;
  4.     if(sm.topLevelSystemManager.toolTipChildren.numChildren){//patch to avoid RTE//
  5.         sm.topLevelSystemManager.removeChildFromSandboxRoot("toolTipChildren", DisplayObject(toolTip));
  6.     }
  7.     // hide effect?
  8. }

In addition to correcting my errant destroyToolTip call, this solved any future unknown RTE’s around that issue.

Alternately, if you don’t want to monkeypatch the ToolTipManagerImpl class, you can wrap your destroyToolTip call in a try/catch error block.

Adobe Flex 3.5 SDK Released

Posted in News, Flex, Flex 3 by Joeflash on the December 15th, 2009

Today Adobe released version 3.5 of the Flex SDK.

I noticed that the Flex Downloads and the Flex 3 Release Notes pages have not yet been updated for v.3.5. Let’s hope Adobe releases the automation and visualization SWCs for v.3.5 as well.

UPDATE Jan 23, 2010: As reported on the Flex Team Blog on January 5th, the datavisualization and automation libraries are now available on the Adobe Flex SDK Downloads page

The Pain of Downloading A Complete Flex SDK

Posted in Flex, Tools, Flex 3, Flex 4, Flash Builder 4 by Joeflash on the November 24th, 2009

Usually, when adding new upgraded SDKs to Flex Builder, say to version 3.4, I’ll go to the adobe open source site and download them from here. Problem is, I’ve then got to hunt around for the download link for the datavisualization components and the automation components (not that I use them all that much, I just like to have them handy).

This page on Adobe’s website tells you that the datavisualization components and the automation components are available on this page. And yet you go there, and no download link. Turns out that the actual download page was listed on the Flex Team’s blog, which leads you to the correct download page here. Good thing I bookmarked it, or I might have a real hard time finding it, cause it sure doesn’t show up on a simple Google search.

And then I’ve got to merge the upzipped datavisualization and automation folder structures with the unzipped Adobe SDK download, to get a “complete” SDK.
What a huge pain.

But there’s an easier way.

While I was installing Flex Builder to a new machine, including migrating all my SDK version folders, I thought, why not take a peek at the latest Flash Builder 4 Beta 2 application installation?

And lo and behold, versions of the following SDKs, which include datavisualization and automation components:

  • Flex SDK version (stable build)
  • Flex SDK version (milestone build)

(You can find the full SDK version number in the flex-sdk-description.xml file in the root of the SDK folder.)

So all I did was copy those folders from the Flex SDK 4 Beta 2 sdk folder to the Flex Builder 3 sdk folder, et voilà! :)

NOTE: the Flex SDK 4 Beta 2 download from the Adobe Labs page is incorrectly named as version in the filename. This zip file is in fact version, and is the exact same zip file as the milestone listed on this page, which you can download here.

Except for one thing…


The Perfect Flex Workflow: Flex Builder 3 with FDT 3.2, Part 1

Posted in Tutorials, Flex, Workflow, Flex 3, Flex Builder 3, Eclipse, FDT by Joeflash on the June 27th, 2009

I’ve long wanted to use FDT to turbocharge my ActionScript coding, but without Flex MXML support I couldn’t justify the cost of getting both Flex Builder and FDT. Then FDT 3.2 came out this past May — finally I had an answer to my prayers with FDT’s new MXML support. And I actually won a copy of FDT Enterprise at 360|Flex Indy: total awesomeness! Now I could decide if once and for all I could get rid of Flex Builder in favour of FDT.

So I tinkered with FDT, converting some of my old projects and seeing how they compiled and ran. And for the most part it all went off without a hitch. I was really quite impressed with FDT’s new Flex capabilities. Also, I had been using Flex Builder for the occasional Flash Professional project for code editing, and FDT now makes that sooo much easier, much like SEPY used to do back in the day.

But it was not to be. Shortly after porting over a Flex project I’m working on, I realize I’d gotten used to having aspects of Flex Builder available in my workflow. Like certain Flex project settings, and the Profiler. Maybe later on I’ll explore the enterprise features of FDT like the Debugger or the SoS logger, but for now all I want FDT to do is gimme that sweet coding savvy which Flex Builder sorely lacks. I mean, there isn’t a single Eclipse-based IDE or plugin I’ve seen which comes anywhere close to the sheer overwhelmingly awesome coding intelligence and snippet templates of FDT.

So what I’d like to be able to do is use FDT for coding both AS and MXML files, and use Flex Builder for the actual compilation, debugging and profiling. And of course the faster compiler and the Network Monitor in Flash Builder 4, when it’s released.

So how do I get the best of both worlds? They’re both available as plugins, so I should be able to install and use them both, right?

Professional Flex 3 Book Advance Launch at 360Flex!

Posted in AIR, Books, Flex, Projects, Publishing, Flex 3 by Joeflash on the May 15th, 2009

As some of you may know, the eight of us have been eagerly awaiting the publication of our book, Professional Flex 3. Well, I’ve just received confirmation the book will be out in stores around end of May, and that Wrox will have 20 advanced copies of the book, hot off the press (literally), ready for givaways at 360|Flex in Indianapolis this coming week.

Yesterday a colleague of mine asked how our book was going, and how big was it. What I told him sums it up pretty good:

8 authors, 1400 pages, 75 chapters, 12 sections, 750MB of code, 18 months.

You can download a PDF of the table of contents here to give you an idea. It’s a hefty volume — the ToC alone is like 31 pages!!

You can also reserve your copy on Amazon now, or buy it from the publisher’s site when it’s out in stores.

Professional Flex 3 Book Cover
Authors from left to right: Joseph Balderson (me), Andrew Trice, Jun Heider, David Hassoun, Todd Prekaski, Joe Berkovitz, Tom Sugden, [Peter Ent not present]

I cannot say enough about these guys, it’s been hugely awesome working with my co-authors throughout this process, including the tech editors and all the great folks at Wrox. This has been a monumental and amazing journey, for all of us. A year and a half ago, I wanted to write the most kick ass, comprehensive and exclusive Flex 3 book out there. To really paint a broad and deep view of the entire Flex ecosystem of technologies. So after getting together seven other amazing programmers and communicators, and writing for many many months, we’ve done it. There are things in this book that you will not find anywhere else.

Converting Flash Projects into Flex

When converting from a Flash CS3/4-based project, to a Flex-based project, there are not just one or two conversion paths to consider, there are many, all of which depends on the Flash project in question.

I’m on a discussion on LinkedIn, in which one guy asks if we know anyone who can do a Flash-to-Flex conversion project, which evolved into a discussion on techniques. Rather than post a pages-long reply, I thought I’d post it here instead:

First, for any Flash-to-Flex conversion to go smoothly, you’ll need at least one person on your team with a good dose of real-world experience with both Flash and Flex-based RIA projects (Flash banners do not qualify ;)), to guide the conversion process and make sure the best deployment strategies are implemented.

As far as the conversion path, there are several possibilities. Depending on the kind of project, you may want to migrate some, most or all of the project to Flex. When migrating from Flash to Flex, you’re not just migrating code, you’re migrating from a visual asset instantiation and state management environment to a purely coding-based methodology (if we forget for a second about Design View in Flex Builder).

Help me speak at 360|Flex (and kick some ass in Flex Builder)

Posted in Flex, Workflow, Flex Builder 3, Conferences by Joeflash on the January 17th, 2009

John Wilker, one of the organizers of 360|Flex, has put up a voting system to help decide from 124 speaker submissions which 40 make the cut. If you wanna find out how to kick some ass in Flex Builder, like how to tweak the Eclipse JVM to speed up compile times, use Subclipse for subversion, or code like a mad dog, go vote for my talk. Full description as follows:

Kicking Ass and Taking Names: Optimizing Flex Builder Performance and Workflow

Flex Builder is a great tool. There are times when using this tool is great, grand, works like a charm. And other times it’s an excruciating experience akin to waiting for paint to dry while a crack team of ninja monkeys shove bamboo under your finger nails. This session will show you how to kick some serious ass in Flex Builder: speed up the IDE, code faster, leap tall buildings in a single bound and shoot lasers out of your eyes. (Okay, maybe not the lasers part, but still.) In this session we’ll be talking about:

  1. Optimizing Flex Builder Performance
    • Project Development Best Practises
    • Speeding up Eclipse
    • The Heap Status Indicator
    • Why Compilation Slows Down
    • Command-line Startup Options
    • JVM Memory Tuning,
  2. Using Language Intelligence
    • Code Assist, Syntax Highlighting, Mark Occurrences, Go to Defintion, etc.
    • Code Preferences
    • The Class Outline View & Sort Options
  3. Managing Workflow
    • Useful Keyboard Shortcuts
    • Search & Refactoring
    • The Diff Tool
    • Layouts for Productivity
  4. Customizing The Workbench
    • Custom Shortcuts
    • Customizing the Editor (Syntax Colouring, Changing the Editor Font Size, Bookmarks, etc.)
    • Editing the Workspaces List
    • Migrating a Workspace without getting an ulcer
  5. Code Versioning in Flex Builder
    • The Built-in Eclipse History / CVS
    • installing and using the subclipse subversion plugin
  6. Assorted Plugins (a melee of Eclipse plugins that’ll make your life easier)

Vote Now!! : )

And here’s my official conference bio (in case you’re wondering who the hell this guy is):

Joseph Balderson (aka “Joeflash”) is a freelance Flex and Flash Platform Developer living in central Ontario, Canada. He spends most of his time in his home studio mainlining code like a junkie on a binge tripped out on trance music, surrounded by three loving cats whom he’s training to meou on cue so they can answer the phones for him (but so far no success). In his spare time he… wait, what spare time?? Joseph is a staff writer at CommununityMX, and lead author on the upcoming book
Professional Flex 3 by Wrox/Wiley Publishing.

Moving a Flex Builder/Eclipse Workspace Without Importing Anything (Update)

Posted in Flex, Workflow, Flex 3, Flex Builder 3, Eclipse by Joeflash on the November 27th, 2008

In the last post, I examined how to move a Flex Builder/Eclipse workspace to a different directory location without re-importing all your projects. Only it didn’t work as well as expected. I finally figured it out, but use at your own risk, since this involves editing Eclipse binary metadata files.

Currently there is no user-friendly technique for moving an entire Eclipse workspace folder to a different directory. This I most wanted to do because the current technique involves the painstaking task of creating a new workspace, then reimporting all projects, reconfiguring all compiler settings, and then re-imputing all the SVN location data for Subclipse. Blech!!

I wanted to move all my workspaces from my C:\ drive to a C:\_fx3\ directory to get them off the root drive. But I don’t have whole days to mess around with importing projects and making sure all the settings have been imported faithfully. I just wanted to move entire workspace folders to the new directory, make a few metadata file hacks, and be done with it.

Well, as it turns out, it’s not that easy. What makes all the difference for most workspaces are not the XML metadata, which seems to be mostly for caching, but the .location files in the metadata project directories, which is where the absolute directory location for each project folder is referenced. Problem is they’re not meant to be user-edited. So use this technique at your own risk, as other absolute directory dependencies may exist that I’m not aware of. For now consider this an experiment in progress.

1. Copy your workspace to the new directory location.

2. Edit the XML metadata files in the workspace folder as detailed in this last post.

Now here’s where it gets interesting.

3. Find the .location files in the workspace metadata. They are located in the

\{workspace dir}\.metadata\.plugins\org.eclipse.core.resources\.projects\{project folder}


3. Open up each .location file in a Hex Editor application. I’m using the free Hex Workshop utility from pbsoft.

Now let’s take a look at the process for editing one of those files.

4. Edit the URI in the binary data. In the Hex for each file you will see the characters “URI” followed by the absolute directory path for the project folder in question. Edit the path, making sure to add or delete bytes as required.

In my .location file, the old path is:


editing the .location file - start

I edit the new path to be


5. Edit the byte before the “URI” to be the new character length of the path.

If your code editor has hex-to-dec conversion, as mine does, you can see that the character length of my old path, which includes “URI”, is hex 2C or 44 characters (see image above).

Select that byte value, and replace it with the character length of the new path. I got the character length by using word count in MS Word (Tools > Word Count…).

URI word count

The length is 49 characters, which is hex 31.

editing the .location file

5. Save the file.

6. Repeat for each .location file.

Now when load up Flex Builder and point to the new workspace location, I verify that the project does indeed point to where I told it to in the .location file. And my SVN locations are conserved, as are all my preferences. YAY!! :)

verifying the successful workspace move

Unfortunately, although this hack works, it’s a lot more trouble (or at the very least the same) as making a whole new workspace and importing each project one by one. I had to Hex edit over 20 files to move the entire workspace — which could hardly be considered a time-effective solution. I can make things easier on myself my copying the entire workspace to my new directory, but I still have to delete and recreate the workspace metadata by pointing to that new workspace folder, and then re-import every project in that workspace. Still, I learned quite a few things about Eclipse in the process, which was partly the goal of the exercise for me anyways.

Although I’ve used it for a few days now and I have not seen any compile or file referencing problems, and it seems like a sound solution, this technique has not been battle-tested, and I’m not an Eclipse developer by any stretch, so I’ll say it again:
use this technique at your own risk. Don’t come crying to me if this hack corrupts or messes up your Flex Builder or Eclipse workspace in any way.

If indeed this hack proves to be stable, as it seems to be, the next step would be to create a batch file or something that could at once copy the complete workspace directory to a new location, seek out and edit all the required XML metadata files with the correct path references, and hex edit all the .location files with the changed URI and adjust the length byte accordingly. Maybe even a custom eclipse plugin written in Java? Hmmm… But that task lies beyond my time and current programming abilities at present, so I will leave you with that final tantalizing thought.

(maybe some enterprising Eclipse developer will read this and decide to surprise us with a plugin, hint hint ;) )

Flex Builder Tip: Moving an Entire Workspace in One Step Without Importing Anything

Posted in Flex, Workflow, Flex 3, Flex Builder 3 by Joeflash on the November 24th, 2008

I had a situation recently where I had way too many workspaces sitting in my root C: drive folder, so I decided I wanted to move them to a subfolder with a very short name like “_fx” just so all my Flex workspaces are all in the same place, and to make backup archiving easier.

If you’re wondering, I have dozens of workspaces, one for each client and/or writing project, each of which has an average of 20+ projects.

Problem is, the conventional way is slow. Really slow. I’d have to create a new workspaces directory location (C:\_fx in my case), and import every single project into every new workspace. And even with saving preferences, I’d lose things like Subversion site locations in the Subclipse perspective. And with over 20 workspaces,. each with an average of 20 projects… I’d be at it for weeks. So I needed a shortcut.

So I dug around in the workspace metadata files, and eventually found where the directory locations reside for each project in that workspace. Luckily, it’s all in one file, so the hack is relatively simple.

Correction: unfortunately it’s not one file you have to edit, it could be a few XML files. And unfortunately this hack doesn’t work with all workspaces unfortunately. See below.

1. Make a copy of your workspace folder to the new location. Don’t move it, in case anything goes wrong. I found this out the hard way by wiping out the metadata for a workspace with over 30 projects — ouch!

2. Find the .metadata folder for the workspace.

3. Find the following files and open them in a text editor:





4. Find & Replace all instances of the old directory location with the new one.

For example, for my \profx3book workspace, I replaced all instances of “C:\profx3book\” with “C:\_fx\profx3book\“.

5. Save the file, and point Flex Builder to the new workspace. Once you’re sure everything is where it should be, delete the files in the old location.

Et voila!

PS: Yes, I know, the above lists five steps, not one — but really it’s only one step: replacing the location string in the workbench.xml file.

PPS: Important Caveat: Search for all .location files in the workspace .metadata folder. If there any files found, this technique might not work, since the directory location for that project is stored in .location files as binary data, and cannot simply be edited with a text editor. So use this technique at your own risk.

Flash-Flex Integration: Coding With Flash Components in Flex Builder

Posted in Flash, ActionScript 3.0, Flex, Flex 3, Flash CS3 by Joeflash on the July 9th, 2008

In the last article on Community MX, we looked at how to use Flex Builder as the ActionScript 3 editor for a Flash-compiled project. But if you are using any Flash CS3 components, Flex Builder is unable to recognize those classes. In this article, we will take a look at how to get Flex Builder to recognize the Flash CS3 Component classes for editing ActionScript 3 files in Flash CS3 projects.

The Flex Builder 3-Flash CS3 Editing workflow
How do we get Flex Builder’s code assist to recognize Flash CS3 Component classes?

( I’ll give you a hint: you find all the fl.* class locations in the Flash CS3 installation directory, and reference them as external source paths in Flex Builder )

For the full, step-by-step explanation, the tutorial is available here on Community MX.

Next Page »