mikemo

Thanks to everyone who came to David’s and my talk at MAX today, Extending Flex Builder. I promised to post the sample code for the part of the talk which discussed design.xml.

So here it is. This ZIP file contains two projects:

• MyLibrary is the main interesting part. It contains design.xml, a Flex manifest, and a sample component. See the slides (linked above) for an explanation of how all this stuff hooks together.
• MyFlexProject is just a simple Flex Project that has MyLibrary on its library path, so that you can see that when you open the Flex project’s main app in design view, the library’s Calculator component shows up in the “Mike’s stuff” folder of the Components view (as opposed to the default, the “Custom” folder), and that if you click on the calculator that is already in the document, the list of properties in the Properties view has been customized, with the “Layout:” property showing up there.

To reiterate, the sample by itself isn’t quite enough — you really need to see the slides (starting at slide #23) to understand the context. And, I will soon be writing an Adobe Developer Center article with much more detail.

There are two things I wanted to mention about the talk David and I are doing tomorrow, “Extending Flex Builder” — David already mentioned this on his blog, but in case you missed it, the documentation team has posted the docs for Flex Builder’s Code Model API and Design Model API up on adobe.com. Previously, the only way to find this documentation was by running Flex Builder and then going to the help — but as you all know, if Google can’t find it, it doesn’t exist. So, thanks, doc team!

Also, David posted the sample code for tomorrow’s talk. See his post here.

I wanted to tell you all about some of the exciting debugger features we've been working on, which will be in Flex Builder 4, including several of the most common requests. All of the features listed below are in the preview release of Flex Builder that we gave out at MAX, with the, um, exception of exception breakpoints, which are not yet in the product. If you were at MAX, give these features a try, and let us know your feedback! If you weren't able to make it to MAX, don't worry, this stuff will eventually show up in a beta on Adobe Labs, and then of course in the final product as well.

Conditional breakpoints

Suppose you have set a breakpoint, but that line of code is reached hundreds of times, and you only care about the case where a variable 'x' is unexpectedly equal to null.  Just right-click on the breakpoint, go to its properties, and add the condition:

For some extra breakpointy goodness, you can also set a hit count on any breakpoint -- e.g. a hit count of 5 means, don't halt until the fifth time that line of code is reached.

Awesome new expression evaluator: function calls, E4X, regular expressions, etc.

Going along with conditional breakpoints is a vastly improved expression evaluator.  It is used when evaluating conditional breakpoints, in the Expressions view, and in debugger tooltips.

For one thing, you can now make function calls directly from the Expressions view (as well as from conditional breakpoints):

mystr.indexOf("test")

Also, regular expressions and E4X expressions can be quite tricky to debug; with the new expression evaluator, you can just type them into the Expressions view and immediately see the value.  (The one exception is you can't use E4X filter expressions such as "myxmlvar.(@id=='3')".)  For example, suppose "customers" is an XML object -- you can do expressions like these in the Expressions view:

myCustomersXML.customer.@name
myCustomersXML..zipCode
myCustomersXML.customer[0].@name

Here is a regular-expression example that you could put in the Expressions view or a breakpoint condition:

mystr.match( /[0-9]+/ig )

You can use the ternary ( ?: ) operator:

mystr.length>=3 ? mystr.charAt(2) : "too short"

You can use the "is" operator (this is especially useful in conditional breakpoints):

obj is String

The possibilities are limitless. ===, !==, string concatenation, etc. -- almost any other ActionScript expression you can think of, you can put it in the Expressions view or a breakpoint condition.

Watchpoints

Watchpoints tell the debugger to immediately halt when the value of a particular variable changes. Suppose you have a variable whose value keeps changing out from under you, and you can't figure out who is changing it. With a watchpoint, it's trivial -- just set the watchpoint and run your code.

(Flex Builder watchpoints are set on a particular instance of a variable. For example, you set a watchpoint on the _width field of a button "myButton", not on the _width field of all Buttons.)

Exception breakpoints

The debugger always halts immediately whenever there is an uncaught exception. But sometimes, you want the debugger to halt even on an exception that is going to be caught by a try/catch block in your code.

That's what exception breakpoints will let you do. You will be able to say, for example, "Always halt in the debugger whenever a TypeError is thrown, even if it is going to be caught."

Run to line

A minor feature but still quite nice to have: Run to Line (Cmd+R on Mac, Ctrl+R on Windows) is a quick way to set a temporary breakpoint on the current line, then run until you get there, and then automatically clear the temporary breakpoint.

Network monitor

A major addition, this allows you to easily see the network traffic that is going back and forth between your app's front end and its back end.

Click for a closer view: