Monthly Archives: March, 2008

Changes from Flex Beta 3 to Flex 3 Release

Some customers have asked us what changes went into the Flex SDK from Beta 3 to our release. I tried to find this information via our public bugbase, however, there didn’t seem to be one. Instead, I went through all of the developer changelists between these two public releases and made a list. Hopefully, this list will help your resolve any issues that you have moving from Flex 3 beta 3 to the released version. All of the changes were bug fixes.

AIR Component Changes:

SDK-13902: Download source link fails in AIR view source. (changes made to WindowedApplication class)

SDK-14062 : DragProxy does not show up in DataGrid when running on AIR

SDK-14300, SDK-14399: minWidth, minHeight, maxWidth and maxHeight changes to fix various bugs.

SDK-14544: Popups in an mx:Window were showing up behind the <mx:Window>. This bug affected Menus, Alerts, PopUps and Tooltips in AIR.

List Based Component Changes:

SDK-13908: Runtime error on dragDrop for DataGrid

SDK-13902: TileList did not recycle rows.

SDK-13807: Items disappear as you move items around and scroll in a Tree.

SDK-13977: Horizontal TileList and List with offscreenExtraRowsOrColumns dragDrop cursor position is incorrect on a scroll

SDK-13980: List component gets into a bad state with empty rows if you drag and drop and have offscreenExtraRowsOrColumns set.

SDK-13540: Runtime error when navigating List or Tree using pending simulator

Tooltip Changes:

SDK-13465: Unexpected toolTip shows up

Cross-versioning Bug Fixes:

SDK-13930, SDK-13931, SDK-13945, SDK-13862

Other:

SDK-14044: SWFLoader and SystemManager references to SystemManager were changed to ISystemManager.

Note: This was a manual process of me going through internal check-in emails for the period between Beta 3 and our release. Therefore, I might have missed a couple of bug fixes.

Understanding Flex 3 Migration Issues (Part III)

Here are a few more things that tips for migrating your Flex 2 application to Flex 3:

1. If you are using runtime CSS, be sure to recompile not just your Flex Application, but, also your .css files with Flex 3. You will most likely get an unexpected error if your Application is compiled in Flex 3 and your css swf was compiled in Flex 2.

2. Recompile all of your swcs and modules in Flex 3, as well. If these swcs or modules use Binding, they cause errors in Flex 3 applications if they were compiled in 2. Note, Flex 2 resource bundle SWCs should be usable in a Flex 3 application.

3. When using HTTPService to send/receive XML data, be sure that your contentType=application/xml. The default is contentType=application/x-www-form-urlencoded. The default used to work in Flex 2 even if  you were sending XML. In Flex 3, it doesn’t work out as pointed out by one of our customers in bug SDK-14811. For more details, please check out that bug.

4. To find out more about backwards compatibility issues that are actually bugs, you should search the public Jira bugbase for “regressions”. Regressions are bugs that exist in Flex 3 that worked correctly in Flex 2. To search for regressions, do the following:

– Go to http://bugs.adobe.com/flex and login. Register, if you have not registered yet.

–  From the menu bar at the top, select “Find Issues”.

– Specify your search requirements on the left. Be sure to look under “Custom Fields” and find the “Regression” field. Select “yes”.  Under “Issue Attributes”, look for the “Resolutions” field and select the last option “Deferred”.

– Click the “View” button at the top or bottom of the search criteria.

* This search will give you all of the regressions that were not fixed and therefore “deferred”.

Understanding Flex 3 Migration Issues (Part II)

Panel Changes:

Issue during migration: Panel Skin no longer displays correctly

Cause of compatibility issue: To make skinning a Panel easier, the skin specific logic was moved into a new PanelSkin. The Panel specific code in HaloBorder was also moved into PanelSkin. The borderThicknessLeft/Right/Top/Bottom styles are now only implemented by PanelSkin. These styles used to be implemented by Panel. Panel now relies on its border skin to provide the borderMetrics, which is consistent with the rest of the controls and containers.

Fix: For your PanelSkin, if you were extending HaloBorder, Border or RectangularBorder, extend PanelSkin instead. I’ve written another post on this subject:

https://butterfliesandbugs.wordpress.com/2008/01/30/migrating-custom-panel-skins-from-flex-2-to-flex-3-moxie/

Issue during migration: With the public Flex 3 beta, my Panel skin worked, but, it doesn’t work in the released version.

Cause of compatibility issue: In the beta, we supported setting the Panel’s borderMetrics of a skin to the scale9Grid, if it was present. We removed this functionality before the release because of some problems that some users were facing.

Fix: You can’t rely on the scale9Grid of the skin to be used to layout your content.

DataGrid Changes:

Issue during migration: Your skinned DataGrid header no longer looks correct.

Cause of compatibility issue: Again, to make customizing a DataGrid header easier to skin, the logic from drawHeaderBackground is now implemented in a DataGridHeaderBackgroundSkin. In Flex 3, the headerBackgroundSkin style was added.

Fix: Extend DataGridHeaderBackgroundSkin to create a custom DataGrid skin. Then, assign this skin to the DataGrid with headerBackgroundSkin.

General Changes:

Issue during migration: A compile error like – Error: Implicit coercion of a
value of type mx.core:IUITextField to an unrelated type flash.display:DisplayObject.

Cause of the compatibility issue: In Flex 3, the protected variables that were UITextField are now of type IUITextField. These changes were done to enable versioning in Flex 3.

Fix: you need to cast the textfield to a DisplayObject.
(e.g. addChildAt(embedTextField,getChildIndex(DisplayObject(textField))); )

Understanding Flex 3 Migration Issues (Part I)

After several public and private betas, Flex 3 was released along with AIR 1.0 last Monday. Yipee! We’ve so far heard several customers who are looking for an official migration guide for getting their Flex 2 applications to work in Flex 3. I’m sorry to say that there isn’t an official migration guide. The reason is because from Flex 2 to 3, there were very few (if any) API changes. It was a MUCH bigger transition for applications going from Flex 1.5 to 2.0 when our product went through a huge API scrub and move to Actionscript 3.0.

Still, some of you may be finding that your application doesn’t quite behave the same or look the same in Flex 3.0. For these problems, your best two resources would be two backwards compatibility docs provided by Adobe’s doc team

http://learn.adobe.com/wiki/display/Flex/Backwards+Compatibility+Issues#BackwardsCompatibilityIssues-BackwardsCompatibilityCompilerOption

This document provides a list of changes in the Flex Framework that are supported by the a backwards compatibility flag in the compiler (-compatibility-version=2.0.1). For example, padding in Button never worked correctly before Flex 3. So, we fixed it. However, some people who may rely on the old measurement logic of the Button may not want to change their code to work with Flex 3’s padding changes. In your application, you can bring back the old behavior in Flex 2.0.1 by compiling their applications with the additional compiler argument -compatibility-version=2.0.1. However, beware, using the backwards compatibility flag is a “all or nothing” situation. If you compile your application with this flag, you will bring back all of the 2.0.1 behavior in the above document. You cannot pick and choose which compatibility changes to revert back.

There is also one document of backwards compatibility changes that are not supported by the -compatibility-version compiler argument. These changes come with Flex 3 and you need to live with it.

http://learn.adobe.com/wiki/display/Flex/Backwards+Compatibility+Issues#BackwardsCompatibilityIssues-ChangesNotSupportedByTheBackwardsCompatibilityFlag

For this week, I thought I would post about some changes in the framework that will likely cause some differences in Flex 2 applications.

Button Changes

Issue during migration: Button labels are now truncated. For example, this code produces a truncated label in Flex 3, but, not Flex 2.

<mx:Button label=”blue moon party” width=”105″ />

Cause of compatibility issue: In Flex 3, all Buttons have paddingLeft, paddingRight, paddingTop and paddingBottom of 10, by default. Padding styles didn’t work in Flex 2.0.1. The space to the left and right of the Button label in Flex 2.0.1 varied.

Fix: Adjust the paddingStyles. For example –

<mx:Button label=”blue moon party” width=”105″ paddingRight=”1″ paddingLeft=”1″/>

Issue during migration: The Event.CHANGE event no longer triggers on a Button or CheckBox unless there is user interaction. If the selected property changes programatically, the event doesn’t trigger.

Cause of compatibility issue: There needed to be a distinction of changing the selected property from user interaction vs programmatically.

Fix: If your code changed the selected property, it should know what to do when this happens.

DataGrid Changes:

Issue during migration: DataGrid code that relied on rowCount does not behave the same.

Cause of compatibility issue: rowCount and lockedRowCount no longer include the header. Also, the itemClick event’s rowIndex property returns 0 for the first row of data.

Fix: Adjust your code to look for different rowCount values. Most likely, you’ll need to subtract 1 from any rowCount value used in Flex 2.0.1.

Issue during migration: You get a runtime error or wrong behavior in a custom component that subclassed DataGrid. In this subclassed component, you used MyDataGrid.getChildAt(…) to access various children of the DataGrid, like the vertical scrollbar.

Cause of compatibility issue: The order of children in the DataGrid was changed. For example, in Flex 2, MyDataGrid.getChildAt(3) used to yield the vertical scrollbar. In Flex 3, it doesn’t. MyDataGrid.getChild(4) yields the scrollbar. In general, you shouldn’t expect the order of children to stay the same. We don’t guarantee this.

Fix: If possible, don’t use getChildAt to access internal components of the DataGrid. Otherwise, adjust which child you are accessing.

more ahead…