Flex 3:Backwards Compatibility Flag
From Adobe Labs
Backwards Compatibility Compiler Option
A new compiler argument -compatibility-version=2.0.1 was added to the Flex SDK. This compiler argument will allow your Applications to use some of the Flex 2.0.1 behavior over the new Flex 3 behavior. Below, you will find a table of all the backwards compatibility changes in Flex 3 that support the use of the -compatibility-version argument.
Note: You cannot pick and choose which of the Flex 3 behavioral changes (below) you want to keep vs which Flex 2.0.1 behavior you want. If you compile with the argument -compatibility-version=2.0.1, you will get all of the Flex 2.0.1 behavior described below.
Here is an example of using the flag:
$./mxmlc -compatibility-version=2.0.1 ../samples/explorer/controls/ButtonExample.mxml
To use the backwards compatibility flag in Flex Builder, go to the 'Properties' of your project. Select 'Flex Compiler'. In the 'Additional compiler arguments:' text field, add -compatibility-version=2.0.1 to whatever else is already there. Click 'OK' and your project will now compile with all of the Flex 2.0.1 behaviors described below.
Backwards Compatibility Changes in Flex 3.0
| Brief Summary | Behavior in 2.01 | Behavior in Moxie | When will a user encounter this issue? | |
|---|---|---|---|---|
| Button Padding Improvements | Button did not respect paddingLeft, paddingRight, paddingTop and paddingBottom styles. Button had some hacks that were affecting the size and position of the label placement. | All padding styles work for button. | If a user set a width on their Button, they may notice truncated text for the label. For example:
<mx:Button label="Submit" width="60" /> This Button in 2.01 had less than 10 pixels of space on the right and left to accomodate the full label. However, in Moxie, the default paddingLeft and paddingRight is 10 pixels. Since, these padding styles now work, the "Submit" label is now truncated. To get around this, you can set the paddingLeft and paddingRight styles to be smaller. For example:
<mx:Button width="60" label="Submit"
paddingLeft="4" paddingRight="4" />
Other users who set padding styles on any Button component will be affected by this change. A Flex 2.01 Button and a Flex 3 Button with the same padding style values will have different sizes. | |
| Buttons with an icon and no label ignored the padding values. | Buttons have paddingRight and paddingLeft set to 10 by default | Applications using Buttons that have an icon and no label will be different sizes. To make your icon Buttons look like the Flex 2.01 buttons, you should set paddingLeft and paddingRight on these Buttons to 0. | ||
| For a DateChooser year navigator skin, the measuredHeight getter returns a larger value because of the changes in button sizing. | For a DateChooser year navigator skin, the measuredHeight getter was smaller. | Someone using a custom DateChooser year navigator skin. | ||
| RadioButtons did not take into account padding when determining their height. The default height of a RadioButton was 18 pixels. | RadioButtons now take padding into account for height measurements. The default height of a RadioButton is 22 pixels in Moxie. (This change was made to fix SDK-11907) | Anyone using a RadioButton | ||
| DataGrid Header Skinning Changes | To customize the DataGrid header background, you would subclass DataGrid and override the drawHeaderBackground function | The logic from drawHeaderBackground was moved to a new skin called DataGridHeaderBackgroundSkin. Also, a new style called headerBackgroundSkin was added. | Applications that subclassed DataGrid and changed drawHeaderBackground. | |
| Menu's default horizontalGap has changed to 6 pixels and separate space is given for an icon vs a RadioButton or CheckBox (SDK-11780) | horizontalGap for Menu was 0. If a Menu had a RadioButton and icon, the two would overlap. | horizontalGap is now 6. Separate space is given for a RadioButton/CheckBox vs the icon of a MenuItem | Any Application using and icon style like branchIcon, checkIcon, etc. These Menu's will have a larger horizontalGap, so the Menu's will likely be a little wider. | |
| Changes to how ScrollBars layout | width of a scrollbar was determined by the upArrow width | width of a scrollbar is determined by the largest width among the upArrow, downArrow, track, and thumb. | If customers are subclassing the Scrollbar classes or using custom skins for their Scrollbar. | |
| Disabled ScrollBars have a new skin SDK-9411 | There is no separate skin for the buttons on a disabled scrollbar. | A disabled state was added to ScrollArrowSkin. The scrollTrack was changed from a DisplayObject to a Button. Lastly, the ScrollTrackSkin now supports button states. | Applications that display scrollbars in any container or component when they are disabled. | |
| upArrow, downArrow, track, & thumb were left-aligned | upArrow, downArrow, track, & thumb are center-aligned | If customers are subclassing the ScrollBar classes or using custom skins of various widths. | ||
| thumb width was the width of the ScrollBar | thumb width is thumb’s measuredWidth | If a customer is subclassing the ScrollBar classes or using custom skins. | ||
| Content positioning for controls and containers due to padding | Canvas – padding styles have no effect | Canvas now respects padding styles | Applications specifying paddingLeft, paddingRight, paddingTop or paddingBottom in a Canvas | |
| Constraint based layout rules in content-sized Containers changed | Width was ignored when left and right styles were set for components in Containers where no width is set. In these cases, the preferredWidth of a component was used. Height was ignored when top and bottom styles were set for components in Containers where no height is set. In these cases, the preferredHeight of a component was used. For example:
<mx:Canvas id="mycanvas">
<mx:Button
left="50"
right="50"
width="100"
id="b"/>
</mx:Canvas>
This would be a 40 pixel button. | Width and height are now honored for components with contstraints set in content sized containers. In the above button, the width would be 100 in Moxie. | Applications will be affected where components specified width along with left/right styles in content-sized containers and components that specified height along with top/bottom styles in content-sized containers. | |
| FormItem Padding Bug Fix | FormItem adds unnecessary extra padding underneath the controls when there are more than one controls. | No extra padding is allocated underneath a FormItem control. | Applications using FormItem with multiple controls. | |
| Panel now supports Scale-9 Grid | Panel's skin used HaloBorder | The Panel's skin now uses a new PanelSkin class. | Applications that created custom Panel skins that extended HaloBorder or Border. Some measurement logic was removied from the Panel class and put into the PanelSkin class. Therefore, older skins may not layout correctly. In these cases, subclassing PanelSkin rather than HaloBorder or Border should solve any issues. | |
| Panel no longer supports borderStyle. | You could set borderStyle="solid" and set a borderColor and borderThickness. | Panel will no longer support any borderStyle besides "default". The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.
Panel will support other borderStyles when using the backwards compatibility flag. In addition, it will be possible to use a combination of explicit heights/widths and absolute positioning to replicate most of the old behavior for alternate borderStyles. PanelSkin's implementation of alternate borderStyles will be mostly working, but won't layout the header and control bar in the correct locations, nor will it size the Panel to be large enough. We need to document these issues. | Anyone setting borderStyle, borderColor and borderThickness for a Panel. | |
| TitleWindow title alignment is a few pixels different. | N/A | To fix SDK-12716, the TitleWindow title alignment logic was changed. | Any applications using TitleWindow. | |
| SubComponent style changes | Accordion: Accordion headers had paddingTop and paddingBottom set to -1 as a hack to solve layout issues. | This hack has been removed and the height of the header has changaed by 1-2 pixels. | Any application using an Accordion. | |
| Accordion: Styles set on the Accordion were always passed on to the Accordion header. | In Moxie, the accordion header no longer gets its styleName set to the accordion. Instead, it only gets assigned to the headerStyleName style if one is specified. The following styles have been deprecated: fillAlphas, fillColors, focusRoundedCorners, horizontalGap, selectedFillColors verticalGap. | Any Applications using any styles on their Accordion expecting them to take effect on the Accordion header. This includes styles such as skin, icon, etc. All of these styles should be specified in a headerStyleName instead. | ||
| ColorPicker: The ColorPicker would pass all of the styles set on it to the swatch panel. | Any styles that affect the swatch panel will not take effect if they are set on the ColorPicker. Instead, the swatchPanelStyleName should be used. The following ColorPicker styles have been deprecated: backgroundColor, columnCount, horizontalGap veriticalGap, previewHeight, previewWidth, swatchGridBackgroundColor, swatchGridBorderSize, swatchHeight, swatchHighlightColor, swatchHighlightSize, swatchWidth, textFieldWidth, textFieldStyleName. | Any Application setting styles on the ColorPicker which affect the ColorPicker swatchPanel. | ||
| ComboBox: The ComboBox dropdown that popped up from clicking on a ComboBox used to inherit its styles from the ComboBox. | In Moxie, the dropdown list does not get any of its styles from ComboBox. Instead, the style dropDownStyleName should be used to specify any style that is supposed to be on the ComboBox's dropdown list. | This will affect anyone setting styles on the ComboBox that should affect the dropdown list. This includes styles like rollOverColor, alternatingItemColors, selectionColors, etc. | ||
| DateChooser: setting cornerRadius and fillColors used to affect the nextButton and prevButton | Setting cornerRadius and fillColors only affect the DateChooser itself, but, not the sub-component buttons. The following styles are being deprecated: fillColors and fillAlphas. | An Application setting cornerRadius or fillColors on a DateChooser. To change the cornerRadius or fillColors of a DateChooser, you need to override the getter for the nextMonthStyleFilters and prevMonthStyleFilters. | ||
| DateField: The DateChooser that popped up from clicking on a DateField used to inherit its styles from the DateField. | In Moxie, the DateChooser does not get any of its styles from DateField. Instead, the style dateChooserStyleName should be used to specify any style that is supposed to be on the popUp DateChooser. The following DateField styles are being deprecated: cornerRadius, fillAlphas, fillColors, headerColors, headerStyleName, highlightAlphas, todayStyleName, weekDayStyleName. | This will affect anyone setting styles on the DateField and expecting them to apply to the DateChooser PopUp. DateChooser will get only inheriting styles from the DateField including. | ||
| LinkBar: LinkButtons in a LinkBar used to inherit its styles from its parent LinkBar. | In Moxie, the style 'linkButtonStyleName' has been added. All styles that should be affect a LinkButton in a LinkBar
should be set though a class selector that is assigned to linkButtonStyleName. | Any Application using styles on a LinkBar that are inherited by the LinkButtons. | ||
| MenuBar: The MenuBar would pass all of the styles set on it to the submenus. | Any non-inheriting styles that affect the MenuBar sub-menus will not take effect if they are set on the MenuBar. Instead, the menuStyleName should be used. Most of the styles on MenuBar that only affect the sub-menus will be deprecated. The following MenuBar styles are being deprecated: backgroundAlpha, backgroundColor. | Any Application setting non-inheriting styles on the MenuBar which affect the sub-menus. | ||
| NumericStepper: setting border styles like borderColor, borderStyle, and borderThickness used to affect the up and down buttons. | Setting border styles like borderColor, borderStyle, and borderThickness does not affect the up and down buttons. It only affects the TextField of a NumericStepper. | An Application setting border styles on a NumericStepper. To change the border styles for a NumericStepper, you need to subclass NumericStepper and override the getters for the downArrowStyleFilters and upArrowStyleFilters. | ||
| TabBar: firstButtonStyleName and lastButtonStyleName were styles inherited from ButtonBar on a TabBar. | In Moxie, you should be using firstTabStyleName and lastTabStyleName to specify any styles that apply to tab styles. | Any Application using styles firstButtonStyleName and lastButtonStyleName on a TabBar. | ||
| PopUpManager: Any PopUp would take its inheriting styles from the Application if they were not set for the PopUp. | The PopUp receives its inheriting styles from its owner. | This could potentially affect any popup who's owner was not the parent Application. | ||
| ColorPicker is visually darker when alpha is set on it. (SDK-11734) | N/A | N/A | Any Application setting alpha on the ColorPicker might notice a cosmetic difference. | |
| Compiler Parsing Rules for .properties files were changed to more closely follow Java's rules. | Flex 2's rules for parsing .properties files were peculiar, such as removing certain sequences of "bad characters", requiring you to write \\" to get a double-quote, \\n to get a newline, and \\\\ to get a backslash. | Flex 3 will use Java's rules. Go to bug SDK-11000 to get the full changes. | Applications using .properties files. | |
| Form Layout Changes. (SDK-9730) | FormItem layout percentage height did not behave correctly. | Form layout code now uses BoxLayout. Percentage heights and widths should now work correctly. Also, Form and FormItem now support includeInLayout. You may find small layout changes from Flex 2.0.1. | Any Application using FormHeader and FormItem. | |
| For percent layouts, round off is now saved and the extra pixel is distributed to one of the components in the layout. (SDK-10871) | If two the width of a container was 275 pixels and two children that both had width=50%, then, each component would be 137 pixels. The 1 pixel roundoff is not taken into account. | In Moxie, if a container with width=275 pixels and two children with width=50%, then, the components are 137 pixels and 138 pixels. The extra pixel is saved and distributed to one of the components. | Applications using percent width and height values. | |
| Runtime Localization: Compilation of _CompiledResourceBundleInfo | N/A | The new _CompiledResourceBundleInfo class is not autogenerated for SWCs or when the -compatibility-version is Flex 2.0.X. It is only for Flex 3 SWFs. | This does not affect Flex 2.0.1 swfs. This will affect swfs using runtime localization that are also using the compatibility flag. Flex 2.0.1 resource bundle parsing rules will be used when the compatibility flag is used. | |
