More Flex Builder 3.0 debugger features
I’ve been meaning to post this ever since we released Flex Builder 3 Beta 2 a few weeks ago. There are some nice debugger enhancements I wanted to tell you about (in addition to the features that were in beta 1, which I described in June).
Hierarchical variables view.
Reduces clutter in the Variables view by grouping all superclass members in a separate tree node, so by default you only see the members of the current class.
Much faster single-stepping.
Previously, if any variables such as “this” were expanded in the variables view (so that their members were visible), then single-stepping in the debugger was somewhat slow. It is now much, much faster — in fact, single-stepping with variables expanded is just as fast as single-stepping with variables collapsed. In one quick test I just ran, single-stepping in Flex Builder 3 was twenty times faster than in Flex Builder 2. In Flex Builder 3, I can just hold down F5, and even on a slow machine, it is executing about ten single-steps per second.
No more “Where is the debugger” dialog.
Now when the Flash player runs a debuggable application (swf) but can’t find a debugger, it just runs the app, with no annoying dialog. (If you want to force it to prompt for a debugger, do right-click > Debugger on the swf running in the browser.)
No more separate debug swf in your bin folder.
Flex Builder 2 created YourApp.swf and YourApp-debug.swf — and also YourApp.html and YourApp-debug.html. Flex Builder 3 no longer creates the "*-debug" files. This speeds up compilation — Flex Builder only has to create one swf — and greatly simplifies writing code that has to refer to other swfs by filename.
In Flex Builder 3, the files in the “bin” directory are debug files. (Before we ship, we will probably rename that folder to “bin-debug”.) To get the release files, use the Export Release Version command, which creates a separate “bin-release” directory. There are more details in this blog post and in this video.
Removing superclass members is great - if your looking for a property in a flex UI component it can take ages to scroll down (waiting for all the inherited properties to populate). Thanks for the update Mike, FB3 will be a definite purchase now.
I really do like the new Beta and love the feature that you don’t end up with all the *-debug.swf files. There is only one question left that you might be able to answer.
I am trying to use the Moxie M2 as the compile SDK but always get this error: "An internal build error has occurred. Pleas check the Error Log".
Any ideas on why this happens and how I could enable the Moxie M2?
Thanks Andy
Andy, please search for the internal build error in our bugbase, http://bugs.adobe.com/flex . If you don’t see it there, please log one.
For us to track it down, you’ll need to include a sample project that reproduces the problem (including the dot files — .project, .actionScriptProperties, .flexProject, etc.). One easy way to package up the project is to use Eclipse’s File > Export, General, Archive File command.
You will also need to include the error message and full callstack from your error log. The error log is a text file: workspaceroot/.metadata/.log (notice the dots in there, dot-metadata and dot-log).
Coming from the VS IDE world, I’m puzzled as to how I would implement the equivalent of VS Build Configurations. IOW, I want to use the "conditional compilation" features of the flex tools from the FB3 IDE. I see where I can add compiler arguments in the Flex Compiler properties for the project, but it does not allow me to have different values for debug/release builds. Any suggestions?
ps- kudos on the flex debugger… oh, and the VS one too… couldn’t live without them.
Hi Steve, unfortunately, for the time being, conditional compilation can’t be controlled on a per-configuration basis with Flex Builder’s integrated build. Because of that, for now you’ll really need to do command-line or Ant builds if you need conditional compilation.
The "Hierarchical variables view" feature is great, but could be improved… Where can I make a push for suggesting to have a flaggable option to get the Variables View to show other approaches to grasping inherited data? It would be nice to be able to have the following three views.
1 - Show consolidated inheritance (as it currently does).
2 - Show inheritance rescursively, meaning to only show what was inherited from the immediate superclass, and recursively show the inheritance tree through that line.
3 - Show flattened inheritance, meaning to have a seperate "inheritance" tree shown for each object in the root of the Variables view, instead of needing to open the inheritance chain resursively (for example, to be able to find the "name" properly on something that inherits several levels of DisplayObject by opening a tree that could be called "[inherited DisplayObject]). Being able to resursively see deeper into each of the ‘flattened’ inheritances could be an option, but perhaps isn’t really neccessary anymore.
I suppose a picture would be more descriptive, which brings us back to the main question… where do we make feature requests?
Thanks for the feedback and ideas, Victor! You make feature requests (and report bugs) in our public bugbase, which is open and visible to everyone: http://bugs.adobe.com/flex . If you could log the above suggestion, that would be great.
I don’t quite understand your third suggestion; perhaps a picture (even ASCII art) would be a good idea.