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?
When I am coding a large class file with several nested code blocks such as methods, try/catch statements, if statements, for loops, I have to use Notepad++ to have access to Indentation Guides, because this feature is not built into Flex Builder. Indentation guides are vertical lines in the editor that follow the tab stops in the document so that code blocks can be visually tracked.
To me this is an essential feature: it is a crucial element of code assist, enabling me to keep track of all the open and closed blocks. I wish Flex Builder had this feature, which is found in several other code editors. If you want to see this feature in Flex Builder, please go vote for Feature Request #17634 on Adobe JIRA:
[#FB-17634] Indentation Guides in Flex Builder
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
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:
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…).
The length is 49 characters, which is hex 31.
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!! :)
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 ;) )
So I just installed a new version of my firewall software, and now neither FB 2 or FB 3 will start. I get a JVM termination error popup, that’s it. As fortune would have it, Neil Webb had blogged about the same problem just today. So I looked up the issue on the Adobe bugbase, and there I found the answer after a little investigation.
…and apparently it was too high. The moment I ran FlexBuilder.exe directly or the shortcut with a lower max mem at -Xmx768m , it worked, no problem. I found I could push it all the way up to 958m, but no more. At 959m, it crashes, just as before.
No idea why installing new software would affect the maximum memory allocation for the JVM, or why a max of 958. But at least it’s working now.
\*replaces hair torn out of scalp\*
Update 02-04-2008: logged an official bug with the Adobe JIRA bugbase