I just uploaded a new ZIP file to the flexmdi site. This release contains both bug fixes and enhancements, though the additions may be somewhat transparent to a lot of users. I did a pretty bad job of tracking which issues I fixed and closed during this update, but I think there were at least 20 of them. There were a few issues around focus and z-order that were fixed, support for basic truncation of window titles was added, did some general refactoring and MDIManager has a new enforceBoundaries property that when set to false will allow windows to be dragged partially outside of their container. The default value is true and MDICanvas has the same property which just acts as a pass through for convenience.

Window Controls

The biggest changes, however, are around styling and the layout of window controls in the title bar. The MDIWindowControlsContainer class is now the default class responsible for laying out things like minimize, maximize and close buttons. You can create subclasses of this class and then assign them to windows via the windowControls property to give your windows a different appearance. To do basic modifications you simply override the updateDisplayList() method like in any other component and flexmdi handles the rest. You can also override createChildren() if you want a set of controls that differ from the defaults. MDIWindowControlsContainer extends LayoutContainer, so you can set the layout property to achieve either absolute, horizontal or vertical layouts. The default is a horizontal layout like HBox that positions itself on the right side of the titleBar. You can easily implement different layouts though and we've included a couple of them in the examples.

Check out the updated explorer and use the styles dropdown on the top right to see examples what kind of different layouts are now possible. The Windows XP style just uses a different horizontalGap than the default layout but the Mac OS 9 style is significantly different. To lend more power to the layout containers, I also exposed the titleTextField of the windows (via MDIWindow.getTitleTextField()) which is protected by default and the titleIconObject (via MDIWindow.getTitleIconObject()) which is mx_internal by default.

Styling

The other significant work was related to default styling of the windows and implementing a system to allow easy overriding of styles. MDIWindow now has a windowStyleName property that allows you to point it to a master style that will be applied to that window. That style then points to substyles to allow fine grained control over individual aspects of window styling. You can of course also override styles by setting values inline via MXML attributes. A master style might look something like this:

.customWindowStyle
{
    styleNameFocus: "myWindowFocus";
    styleNameNoFocus: "myWindowNoFocus";

    titleStyleName: "myTitleStyle";

    minimizeBtnStyleName: "myMinimizeBtn";
    maximizeBtnStyleName: "myMaximizeBtn";
    restoreBtnStyleName: "myRestoreBtn";
    closeBtnStyleName: "myCloseBtn";

    windowControlsClass: ClassReference("somePackage.MyCustomControlsContainer");
}

I am planning on doing a post specifically about the new styling options but there are a couple of things to note here. styleNameFocus and styleNameNoFocus are just what they sound like. The styles they point to will be applied to the window depending on whether or not it has focus. (Which reminds me, there is now a hasFocus property on MDIWindow.) The other significant piece of the style declaration is the windowControlsClass style which, as you can see points to a ClassReference. This class will be detected and applied when the windowStyleName property is set, if necessary, allowing full control over window styling at runtime.

Default behaviors

The process for preventing/delaying default behaviors has also changed slightly. We have implemented the behavior described by Darron Schall here as it really is more proper than our initial implementation. The gist is that you now use event.preventDefault() instead of event.stopImmediatePropagation() and instead of storing the event for later execution you store a copy of it by using event.clone(). Darron's post is worth reading though so if you have time I would recommend getting the full scoop.

I think those are all of the major changes in 1.1 but I plan on taking a closer look at some of the topics in dedicated posts in the future. I've got a crazy couple of weeks ahead of me but I will do my best to get them up soon. If you have requests or suggestions for particular topics you'd like to see covered let me know in the comments. You can also find the full documentation here and as always, let us know what you think!